安全研究
安全研究、论文、报告与技术分析。
-
Beyond Runtime Enforcement: Shield Synthesis as Defensibility Analysis for Adversarial Networks
Shielded reinforcement learning is typically presented as a runtime safety mechanism that compiles temporal-logic specifications into automata restricting an agent's actions. We argue this is the wrong product. The same automata-theoretic machinery -- specification compilation, product game construction, attractor computation, and winning-region extraction -…
Shielded reinforcement learning is typically presented as a runtime safety mechanism that compiles temporal-logic specifications into automata restricting an agent's actions. We argue this is the wrong product. The same automata-theoretic machinery -- specification compilation, product game construction, attractor computation, and winning-region extraction -Shielded reinforcement learning is typically presented as a runtime safety mechanism that compiles temporal-logic specifications into automata restricting an agent's actions. We argue this is the wrong product. The same automata-theoretic machinery -- specification compilation, product game construction, attractor computation, and winning-region extraction -- is better read as a design-time analytical instrument whose outputs are structural insights about a system rather than runtime constraints on a deployed agent. We instantiate this through a constrained two-player safety game for network defense. The two specifications are enforced asymmetrically: the defender specification defines the unsafe region of the game, whereas the attacker specification restricts the adversary's legal actions during attractor computation. Solving the game yields a defensibility verdict -- a formal certificate that a topology-specification pair is or is not defensible -- with the associated winning region and shield. Beyond the binary verdict, we derive topology-level metrics from the attractor structure and combine them with post-convergence behavior from shield-constrained adversarial multi-agent reinforcement learning. Together these form a defensibility fingerprint capturing both a network's formal safety properties and its operational behavior under adaptive play. A what-if analysis shows that formal defensibility and operational effectiveness capture distinct aspects of security: small architectural changes can produce large shifts in operational outcomes while leaving formal safety margins nearly unchanged. Shield synthesis is thus most valuable not as a deployment mechanism for safe agents, but as a framework for answering architectural questions about whether, where, and how a system can be defended. The defensibility verdict is the output, not the safe policy.扩展字段
{ "arxiv_id": "2606.13621v1", "authors": [ "Achraf Hsain", "Sultan Almuhammadi" ], "categories": [ "cs.AI", "cs.CR", "cs.GT", "cs.LG", "cs.MA" ], "comment": "26 pages, 7 figures, 7 tables. Under review at JAIR. Code: https://github.com/AchrafHsain7/Bastion", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13621v1", "pdf_url": "https://arxiv.org/pdf/2606.13621v1", "primary_category": "cs.AI", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T17:35:40+00:00" } -
Beyond the IT Checklist: Engineering a Reasonable Standard of Care for Cyber Safety
Current U.S. cyber policy, centered on security, often treats documentation of controls and incident reports as a proxy for safety in the built environment. This paper argues that such an approach is inadequate for cyber-physical systems, where digital failures can produce kinetic harm. We construct and code a corpus of critical infrastructure policy documen…
Current U.S. cyber policy, centered on security, often treats documentation of controls and incident reports as a proxy for safety in the built environment. This paper argues that such an approach is inadequate for cyber-physical systems, where digital failures can produce kinetic harm. We construct and code a corpus of critical infrastructure policy documenCurrent U.S. cyber policy, centered on security, often treats documentation of controls and incident reports as a proxy for safety in the built environment. This paper argues that such an approach is inadequate for cyber-physical systems, where digital failures can produce kinetic harm. We construct and code a corpus of critical infrastructure policy documents (N=292, 2000-2025) to examine how "reasonable care" is operationalized across the NIST SP 800-160 Vol.~2 resilience lifecycle. The resulting maps show that obligations are concentrated in the Anticipate phase and emphasize administrative compliance, while Withstand and Recover phases rely heavily on delegated references to IT-focused control catalogs that are poorly aligned with physics-based hazards. We identify three major disconnects: miscalibrated delegated standards, recovery defined as notification rather than engineered navigation, and uneven adaptation requirements across sectors. We then propose a modernized standard of care anchored in hazard-specific traceability, structured assurance cases, and cyber resiliency engineering. Finally, we recommend that federal policy pair these engineering obligations with targeted incentives so that resilient architectures for critical infrastructure become a viable business decision rather than an unfunded expectation.扩展字段
{ "arxiv_id": "2606.13612v1", "authors": [ "Matthew E. Jablonski", "Linton Wells", "Kathryn B. Laskey", "F. Brett Berlin" ], "categories": [ "cs.CR" ], "comment": "6 pages, 2 figures, Accepted for publication and presentation the Cyber Safety Summit, Washington, D.C., 2026", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13612v1", "pdf_url": "https://arxiv.org/pdf/2606.13612v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T17:25:07+00:00" } -
Differentially Private Hierarchical Heavy Hitters
The task of finding _Hierarchical_ Heavy Hitters (HHH) was introduced by Cormode et al. [VLDB 2003] as a generalisation of the heavy hitter problem. While finding HHH in data streams has been studied extensively, the question of releasing HHH when the underlying data is private remains unexplored. In this paper, we study differentially private HHH release in…
The task of finding _Hierarchical_ Heavy Hitters (HHH) was introduced by Cormode et al. [VLDB 2003] as a generalisation of the heavy hitter problem. While finding HHH in data streams has been studied extensively, the question of releasing HHH when the underlying data is private remains unexplored. In this paper, we study differentially private HHH release inThe task of finding _Hierarchical_ Heavy Hitters (HHH) was introduced by Cormode et al. [VLDB 2003] as a generalisation of the heavy hitter problem. While finding HHH in data streams has been studied extensively, the question of releasing HHH when the underlying data is private remains unexplored. In this paper, we study differentially private HHH release in both the streaming and non-streaming setting. In the non-streaming setting, we show the surprising result that the relative error in estimating the residual count for any prefix is independent of the height of the hierarchy and the number of heavy hitters in the stream. Meanwhile, in the streaming setting, although the exact version of HHH has low global sensitivity (as counting queries are 1-sensitive), the approximation functions due to streaming have high global sensitivity, linear in the available space. Despite this obstacle, we show that the absolute error for estimating frequencies in the steaming setting is independent of the available space.扩展字段
{ "arxiv_id": "2606.13563v1", "authors": [ "Ari Biswas", "Graham Cormode", "Yaron Kanza", "Divesh Srivastava", "Zhengyi Zhou" ], "categories": [ "cs.CR", "cs.DS" ], "comment": "This is the updated version of the PODS 2025 conference version. Note that the conference version has a bug in the privacy proof fro the non-streaming version. We have addressed the bug in this full version", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13563v1", "pdf_url": "https://arxiv.org/pdf/2606.13563v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T16:48:35+00:00" } -
Intent-Based Cryptographic API Design for Cryptographic Agility
As organizations move toward post-quantum cryptography, they face the major challenge of updating cryptographic algorithms across large, complex software portfolios. However, most cryptographic APIs in use today were designed around specific algorithms. These APIs expect explicit use of specific algorithms, provide little or no support for policy-based algor…
As organizations move toward post-quantum cryptography, they face the major challenge of updating cryptographic algorithms across large, complex software portfolios. However, most cryptographic APIs in use today were designed around specific algorithms. These APIs expect explicit use of specific algorithms, provide little or no support for policy-based algorAs organizations move toward post-quantum cryptography, they face the major challenge of updating cryptographic algorithms across large, complex software portfolios. However, most cryptographic APIs in use today were designed around specific algorithms. These APIs expect explicit use of specific algorithms, provide little or no support for policy-based algorithm selection, and offer no straightforward way to migrate existing keys to newer algorithms. This makes the transition to post-quantum cryptography challenging. The companion assessment framework identifies the barriers to cryptographic agility and explains why algorithm transition is largely a software engineering problem. To address the limitations of current cryptographic APIs, we identify the principles necessary to design a cryptographically agile API. The design principles are derived from five fundamental architectural characteristics (Abstraction, Stability, Temporal Flexibility, Separation, and Extensibility). We also show how the design principles can be implemented using several examples of Protocol Buffers API design patterns. In particular, we present an intent vocabulary that is based on scopes which allows for decoupling key creation from algorithm identities. It also supports transparent substitutions of algorithms in the applicable scope. Cryptographic governance is enabled by an abstract policy API that does not prescribe the policy format. Keys are represented by stable identifiers and support key evolution operations (rotation, transformation, migration), facilitating migration between algorithms and providers while tracking both the original key identity and its evolution history. With this approach, updating cryptography becomes an operational process without the need to rewrite application code.扩展字段
{ "arxiv_id": "2606.13445v1", "authors": [ "Navaneeth Rameshan", "Gregoire Messmer" ], "categories": [ "cs.CR" ], "comment": null, "doi": null, "entry_id": "https://arxiv.org/abs/2606.13445v1", "pdf_url": "https://arxiv.org/pdf/2606.13445v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T15:05:37+00:00" } -
An Assessment Framework for Application-Level Cryptographic Agility
The impending post-quantum transition to new cryptography will require complete replacement of algorithms within all software. The cryptographic APIs used today make this transition challenging because they were not designed with agility as a concern. There is no method for systematically assessing cryptographic agility as an overall ability. In addition to …
The impending post-quantum transition to new cryptography will require complete replacement of algorithms within all software. The cryptographic APIs used today make this transition challenging because they were not designed with agility as a concern. There is no method for systematically assessing cryptographic agility as an overall ability. In addition toThe impending post-quantum transition to new cryptography will require complete replacement of algorithms within all software. The cryptographic APIs used today make this transition challenging because they were not designed with agility as a concern. There is no method for systematically assessing cryptographic agility as an overall ability. In addition to this, the term itself refers to multiple independent capabilities. Specifically, it includes replacing algorithms, selecting by policy, and substituting implementations. This lack of structured decomposition limits both the evaluation of systems and the development of cryptographically agile APIs. We introduce a component-based assessment framework that characterizes application-level cryptographic agility along seven orthogonal dimensions: three coupling dimensions that measure what the application code knows about algorithms and providers, a cross-cutting decoupling mechanism, a governance authority dimension, and two agility enablers that measure actual migration capability. The framework is non-linear and captures non-hierarchical profiles: a system may achieve high operation decoupling yet low creation decoupling, or strong versioning without externalized configuration. We evaluate six representative APIs (PKCS#11, OpenSSL~3.0, JCA, Google Tink, AWS KMS, and HashiCorp Vault Transit) against the framework, revealing three pervasive and independent gaps: no system supports intent-based key creation, none provides policy-driven algorithm selection (as distinct from access control), and none offers dedicated/first-class operations for algorithm transformation of existing keys. These gaps are individually sufficient to prevent agile migration, explaining why the post-quantum transition remains a software engineering problem despite decades of API progress.扩展字段
{ "arxiv_id": "2606.13425v1", "authors": [ "Navaneeth Rameshan", "Gregoire Messmer" ], "categories": [ "cs.CR" ], "comment": null, "doi": null, "entry_id": "https://arxiv.org/abs/2606.13425v1", "pdf_url": "https://arxiv.org/pdf/2606.13425v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T14:54:10+00:00" } -
Who Pays the Price? Stakeholder-Centric Prompt Injection Benchmarking for Real-world Web Agents
Web agents driven by large language models (LLMs) are increasingly deployed in real-world environments, where they operate over untrusted web content and execute actions with direct consequences. This makes them vulnerable to prompt-injection attacks, in which seemingly benign content embeds adversarial instructions that manipulate agent behaviour. Existing …
Web agents driven by large language models (LLMs) are increasingly deployed in real-world environments, where they operate over untrusted web content and execute actions with direct consequences. This makes them vulnerable to prompt-injection attacks, in which seemingly benign content embeds adversarial instructions that manipulate agent behaviour. ExistingWeb agents driven by large language models (LLMs) are increasingly deployed in real-world environments, where they operate over untrusted web content and execute actions with direct consequences. This makes them vulnerable to prompt-injection attacks, in which seemingly benign content embeds adversarial instructions that manipulate agent behaviour. Existing security benchmarks adopt an \textit{attack-centric} perspective, focusing on the technical feasibility of injections while overlooking the nuanced distribution of resulting harms. In practice, however, prompt-injection risk is victim-dependent: a single exploit can produce asymmetric consequences for different stakeholders, and the same attack pattern may exhibit substantially different effectiveness depending on whom it targets. To capture these properties, we introduce \textbf{\sysname}, a \textit{stakeholder-centric} benchmark to systematically categorize and attribute harm in real-world web agent systems. It distinguishes between affected entities (e.g., user, seller, platform), decomposes the attacks into concrete objectives, and evaluates each case with complementary outcome- and process-level metrics. Our results reveal substantial and heterogeneous vulnerabilities: not a single attack objective is reliably resisted by current agents, and failures distribute across qualitatively distinct modes ranging from \emph{stealthy parasitism} (attack succeeds without disrupting the user's delegated task) to \emph{misaligned disruption} (task disrupted without attack success) and \emph{compounded failure} (both adversarial objective and task integrity simultaneously violated). These patterns are missed by conventional evaluation, highlighting the need for stakeholder-aware assessment of LLM-based agents in real-world deployments. Benchmark is available at https://github.com/StakeBench/SBC.扩展字段
{ "arxiv_id": "2606.13385v1", "authors": [ "Zihao Wang", "Yiming Li", "Yutong Wu", "Zheyu Liu", "Kangjie Chen", "Fok Kar Wai", "Pin-Yu Chen", "Vrizlynn L. L. Thing", "Bo Li", "Dacheng Tao", "Tianwei Zhang" ], "categories": [ "cs.CR", "cs.AI", "cs.CY", "cs.HC", "cs.MM" ], "comment": "32 pages", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13385v1", "pdf_url": "https://arxiv.org/pdf/2606.13385v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T14:12:43+00:00" } -
Split Tallies: A Discrete Certificate Calculus for Auditing Dynamic Ordered Sets in Constant Memory
We study retrospective auditing for dynamic ordered sets maintained by an untrusted party. A passive auditor watches insert, delete, membership, predecessor, successor, min, and max operations, stores five machine words and a flag, and receives a constant-size public tally record per operation. At audit time the maintainer discloses the claimed live vacant i…
We study retrospective auditing for dynamic ordered sets maintained by an untrusted party. A passive auditor watches insert, delete, membership, predecessor, successor, min, and max operations, stores five machine words and a flag, and receives a constant-size public tally record per operation. At audit time the maintainer discloses the claimed live vacant iWe study retrospective auditing for dynamic ordered sets maintained by an untrusted party. A passive auditor watches insert, delete, membership, predecessor, successor, min, and max operations, stores five machine words and a flag, and receives a constant-size public tally record per operation. At audit time the maintainer discloses the claimed live vacant intervals. The method represents order semantics by maximal gaps: gaps are born, cited, consumed, and timestamped, while two hidden field accumulators test equality of the birth and consumption ledgers. Honest executions are accepted with probability one. If any answer in a T-operation session is wrong, acceptance occurs with probability at most (4T+1)/p over one secret field element, against computationally unbounded maintainers. We prove that deterministic and visible-coin auditors require linear state, and that removing the timestamp rule permits an exact replay forgery. A leaf-oriented (2,4)-tree implements the maintainer in O(log n) worst-case time per operation with one extra word per element, and its rebalancing events admit an auditable O(m) envelope over m updates. Checkpoint audits compose with additive error.扩展字段
{ "arxiv_id": "2606.13272v1", "authors": [ "Faruk Alpay", "Levent Sarioglu" ], "categories": [ "cs.DS", "cs.CR" ], "comment": "22 pages, 2 figures, 3 tables", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13272v1", "pdf_url": "https://arxiv.org/pdf/2606.13272v1", "primary_category": "cs.DS", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T12:25:43+00:00" } -
The Invisible Ink of the Android Malware World: A Longitudinal Study on the Usage of Covert Communication Channels
Proxies, VPNs and Tor have long helped the privacy community and users in censored regions to fight censorship. However, the same tools can be maliciously exploited by malware and botnets to conceal their communication to external command and control servers. Despite being a critical concern fueled by the proliferation of malware based attacks, no longitudin…
Proxies, VPNs and Tor have long helped the privacy community and users in censored regions to fight censorship. However, the same tools can be maliciously exploited by malware and botnets to conceal their communication to external command and control servers. Despite being a critical concern fueled by the proliferation of malware based attacks, no longitudinProxies, VPNs and Tor have long helped the privacy community and users in censored regions to fight censorship. However, the same tools can be maliciously exploited by malware and botnets to conceal their communication to external command and control servers. Despite being a critical concern fueled by the proliferation of malware based attacks, no longitudinal studies have analyzed how malware applications use covert channels (CC) to evade detection. We fill this gap by performing the first study of the usage of covert channels in the Android malware ecosystem. To that end, we develop a multistage pipeline that combines static and dynamic analysis to investigate both system and network-level features. We applied this pipeline on a corpus of 3.5M Android malware spanning 2009 to July 2025. Our carefully crafted static validation rules uncovered 288K APKs that used CCs spanning 511 malware families and CC usage growing exponentially from 0.30\% (2012) to 50\% (2025). Overall, in dynamic analysis, we identified 19,308 unique IP addresses being contacted in 85 countries, out of which we were able to explicitly validate the presence of CCs for 59 IP addresses across 17 countries. Further, we performed a longitudinal dataset study spanning over 16 years for CC based malware and found that CC usage has evolved, \textit{e.g.,} some malware adopted by using more than one CCs; others switched between them periodically (one family switched CC usage 40 times from 2019 to 2025).扩展字段
{ "arxiv_id": "2606.13107v1", "authors": [ "Zeya Umayya", "Manan Aggarwal", "Manan Chugh", "Mann Nariya", "Yogesh Kaushik", "Sambuddho Chakravarty" ], "categories": [ "cs.CR", "cs.NI" ], "comment": "21 pages, 23 figures, EuroS&P 2026", "doi": null, "entry_id": "https://arxiv.org/abs/2606.13107v1", "pdf_url": "https://arxiv.org/pdf/2606.13107v1", "primary_category": "cs.CR", "search_query": "cat:cs.CR", "updated_at": "2026-06-11T09:34:55+00:00" }