Network Working Group F. Linker Internet-Draft D. Basin Intended status: Informational ETH Zurich Expires: 3 November 2024 M. Vignati ICRC 2 May 2024 Problem Statement for a Digital Emblem draft-linker-digital-emblem-00 Abstract In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark _physical_ assets. This enables military units to identify assets as respected and protected under international humanitarian law. This draft explores how one could apply the protective emblems to _digital_, network- connected infrastructure using a _digital emblem_, and defines the requirements of a digital emblem, emphasizing security requirements. Notably, a digital emblem has a unique combination of security requirements, namely, authentication, accountability, and a property that we call _covert inspection_. Covert inspection means that those wishing to authenticate assets as protected must be able to do so without revealing that they may attack unprotected entities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 November 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Linker, et al. Expires 3 November 2024 [Page 1] Internet-Draft PS-DE May 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Legal and Historical Background . . . . . . . . . . . . . 4 3.2. Problem Domain . . . . . . . . . . . . . . . . . . . . . 4 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Covert Inspection . . . . . . . . . . . . . . . . . . 5 3.3.2. Authentic . . . . . . . . . . . . . . . . . . . . . . 5 3.3.3. Decentralized Trust Model . . . . . . . . . . . . . . 5 3.3.4. Accountable Display . . . . . . . . . . . . . . . . . 6 3.3.5. Removable & Verifiable Presence . . . . . . . . . . . 6 3.4. Use-Case Scenarios . . . . . . . . . . . . . . . . . . . 6 3.4.1. Personal Devices . . . . . . . . . . . . . . . . . . 6 3.4.2. Constrained Devices . . . . . . . . . . . . . . . . . 7 3.4.3. Servers . . . . . . . . . . . . . . . . . . . . . . . 7 3.4.4. Networks . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Excluded Scenarios . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction International Humanitarian Law (IHL) mandates that military units must not attack medical facilities, such as hospitals. The emblems of the red cross, red crescent, and red crystal are used to mark _physical_ infrastructure (e.g., by a red cross painted on a hospital's rooftop), thereby enabling military units to identify those assets as protected under IHL. The International Committee of the Red Cross (ICRC) recently posed the question: How can one extend such markings to _digital_ infrastructure such as servers and networks? [DE-REPORT] Linker, et al. Expires 3 November 2024 [Page 2] Internet-Draft PS-DE May 2024 The goal of a digital emblem is to prevent cyberattacks on humanitarian infrastructure. Parties to armed conflicts are bound by IHL, and are thus required by law to respect the protective emblems. Other actors may not be bound by IHL, but could still respect a digital emblem. Either out of respect for the humanitarian cause or to avoid unwanted attention when attacking marked assets. A digital emblem can only serve this purpose, though, if it meets a unique combination of requirements. 1. Digital emblems require authentication as assets must not be able to fake protection, for example, by transferring emblems from medical to military infrastructures. 2. Protective emblems must be decentralized, i.e., there must be no central authorities that govern the use or distribution of digital emblems. Under IHL, states themselves determine which parties and assets may display the emblem under their authority. 3. Systems with a decentralized trust model are prone to misuse. Therefore, a digital emblem must be designed so that parties can be held accountable whenever they mark unprotected infrastructure. Protection under IHL stems from law, and laws must be enforceable to have an effect. 4. Those wishing to authenticate assets must be able to verify protective emblems in a way that does not call attention to the fact that they are screening potential targets. We call this property _covert inspection_. This is analogous to looking at a physical emblem from a distance: A flag of a red cross does similarly not raise attention to the fact that its being looked at. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The Problem Linker, et al. Expires 3 November 2024 [Page 3] Internet-Draft PS-DE May 2024 3.1. Legal and Historical Background The Geneva Conventions and their _Additional Protocols_ (APs) constitute the core of IHL and establish legal rules on the conduct of armed conflict. These Conventions and Protocol establish the meaning and usage of protective emblems, namely, the red cross, crescent, and crystal. The emblems have a protective and an indicative function. In its protective function, parties to conflict may apply an emblem to assets that exclusively undertake medical functions, such as vehicles, personnel, or buildings. These emblems inform other parties that they must not be attacked. In its indicative function, an emblem signals affiliation with the International Red Cross and Red Crescent Movement. Since 1949, the Geneva Conventions have been revised. AP I contains additional regulations on how parties to conflict can communicate their status using technical means, like radar transponders and radio signals. Recognizing that technology may progress rapidly, the amendment process for AP I is streamlined. For example, this process could begin through expert consultations convened by the ICRC. 3.2. Problem Domain The concept of a digital emblem touches a variety of stakeholders. First and foremost, there are _emblem issuers (EIs)_, groups that provide medical services or conduct humanitarian operations such as military forces or organizations like Doctors Without Borders. As part of their activities, they may display the protective emblems on their _protected digital assets_, such as mobile devices (tablets, smartphones), servers (both virtual and dedicated), or an intranet. Prior to commencing their operations, EIs must seek permission from competent _authorities_. When they are given permission, EIs can apply digital emblems to their protected assets, which _present_ them to three types of _agents_. _Regular users_ of an asset do not pay attention to the emblem, for example, when they visit a website. _Verifiers_ pay attention to the emblem and only wish to attack lawful (under IHL) targets. They are typically part of an armed force engaged in a conflict. We can assume that most verifiers (typically military units) will be associated with an authority (typically their nation state or an ally), and, hence, that such verifiers can obtain the authentic public keys of their affiliated authorities through secure, out-of- band channels. Finally, we define _adversaries_ as those agents that are willing to violate IHL and search to abuse digital emblems. For example, they may seek to issue emblems to non-protected assets. Linker, et al. Expires 3 November 2024 [Page 4] Internet-Draft PS-DE May 2024 3.3. Requirements The digital emblem's requirements were adapted from the ICRC's report on digital emblems [DE-REPORT]. However, whereas the report introduces requirements on a much higher, abstract level and without a detailed consideration of security, we present a comprehensive list of actionable, technical requirements. The purpose of a digital emblem is to prevent attacks on protected assets by informing other parties about their status under IHL. (Note that IHL also permits the indicative use of an emblem, we subsume this case under the protective use of an emblem for clarity.) The digital emblem's requirements are derived from two important insights. (i) A digital emblem critically requires adoption by verifiers, which (by definition) intend to attack assets not protected under IHL. (ii) A digital emblem should comply with existing IHL, which facilitates the diplomatic process of adopting a digital emblem. 3.3.1. Covert Inspection A digital emblem MUST NOT reveal who is inspecting it. We call this requirement _covert inspection_. If verifiers were to reveal that they are inspecting digital emblems, their targets (potentially unprotected) could use that knowledge to protect themselves against an imminent attack, and verifiers would therefore not inspect emblems. In particular, covert inspection implies that emblem presentation must be _active_, i.e., verifiers will be sent emblems and need not query them explicitly. 3.3.2. Authentic Digital emblems MUST be _authentic_, i.e., a digital emblem only marks assets that are used to provide medical services or conduct humanitarian operations. If it were not authentic, verifiers would risk that their lawful, i.e., unprotected, targets could avert attacks by displaying fraudulent emblems, and verifiers would again not inspect emblems. 3.3.3. Decentralized Trust Model Compliance with existing IHL implies that there MUST NOT be a fixed set of authorities that can regulate how a digital emblem is used, i.e., it must follow a _decentralized trust model_. Linker, et al. Expires 3 November 2024 [Page 5] Internet-Draft PS-DE May 2024 3.3.4. Accountable Display Systems with a decentralized trust model can suffer from misuse. Should a digital emblem be codified in law, it is crucial that any unlawful display of digital emblems can be provably attributed to the respective parties such that they can be prosecuted. Hence, a digital emblem MUST provide _accountability_. 3.3.5. Removable & Verifiable Presence A digital emblem should work just as the physical emblems. Just as a flag with a red cross can be displayed and removed at any time, a digital emblem MUST be applicable to the widest possible range of use cases and digital technologies, and also be easily _removable_. Additionally, agents MUST be able to _verify the presence_ of digital emblems. With physical emblems, unprotected assets will simply not show the red cross. Likewise, in the digital domain, these assets will not present an invalid emblem, but rather no emblem, and verifiers must be able to determine when no emblem was shown to them. 3.4. Use-Case Scenarios In the following, we list a number of use cases that a digital emblem should cover. These use cases were derived in collaboration with the ICRC and a broad range of international experts, including the medical sector, the information technology sector, the military sector, and cybersecurity experts. It may turn out that there cannot be a single design proposal that covers all use-cases. Nevertheless, the number of ways in which a digital emblem can be distributed should be kept minimal. The more interfaces supported by a digital emblem, the greater the burden on verifiers, who would need to check every interface to ensure that they are not attacking a protected asset. 3.4.1. Personal Devices A digital emblem should apply to general purpose, personal computing devices such as laptops, smartphones, and tablets. Typically, such devices have no stable IP address, but have a powerful operating system and support complex applications well. Linker, et al. Expires 3 November 2024 [Page 6] Internet-Draft PS-DE May 2024 3.4.2. Constrained Devices A digital emblem should apply to network-connected devices that are constrained in computing power, bandwidth, or cannot be easily modified, for example, medical or IoT devices. Typically, such devices are deployed in a fixed environment, however, due to power, hardware, or legal constraints, they cannot support complex applications, or their software might not be modifiable at all. 3.4.3. Servers A digital emblem should apply to dedicated and virtual servers, e.g., web or database servers. Such servers may or may not have a stable IP or a domain name associated with them. 3.4.4. Networks A digital emblem should apply to networks that are controlled by one organization, e.g., the ICRC's internal network. Typically, such networks have an IP range associated with them. Each device connected to this network should fall into one of the categories above and could thus be marked individually. However, marking entire networks should drastically ease the burden of deployment, verification, and distribution. 3.5. Excluded Scenarios Notably, a digital emblem cannot be applied to infrastructure that is used for both services worthy and unworthy of protection. A digital emblem must always identify assets that only serve purposes that enjoy protection under IHL. 4. Security Considerations The requirements "covert inspection", "authentic", and "accountable display" are all security requirements, i.e., one must consider powerful adversaries trying to break these requirements when evaluating a proposal for a digital emblem. The original, academic paper proposing _ADEM: An Authentic Digital Emblem_ formally verified ADEM's security, and any subsequent proposal should be rigorously analyzed as well. 5. IANA Considerations This document has no IANA actions. 6. References Linker, et al. Expires 3 November 2024 [Page 7] Internet-Draft PS-DE May 2024 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [ADEM] Linker, F. and D. Basin, "ADEM: An Authentic Digital EMblem", CCS '23 Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, November 2023, . [DE-REPORT] Rodenhäuser, T., Vignati, M., Maybee, L., and H. Johnston, "Digitalizing the Red Cross, Red Crescent and Red Crystal Emblems", November 2022, . Acknowledgments Parts of this draft are based on the initial academic publication describing the proposal _ADEM: An Authentic Digital EMblem_ [ADEM]. Initial work on this project was funded by the Werner Siemens- Stiftung (WSS). We thank the WSS for their generous support. Authors' Addresses Felix Linker ETH Zurich Email: flinker@inf.ethz.ch David Basin ETH Zurich Email: flinker@inf.ethz.ch Mauro Vignati ICRC Email: mvignati@icrc.org Linker, et al. Expires 3 November 2024 [Page 8]