]> ETH Zurich

flinker@inf.ethz.ch

ETH Zurich

flinker@inf.ethz.ch

ICRC

mvignati@icrc.org

Microsoft

tojens@microsoft.com

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.

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? 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.

Work on the digital emblem dates back multiple years. In 2020, the ICRC invited two research institutions, Johns Hopkins University Applied Physics Laboratory (APL) and the Centre for Cyber Trust (CECYT), a joint research centre between ETH Zurich and Bonn University, to develop technical proposals for a digital emblem. These proposals were presented to and evaluated by a group of international experts at the invitation of the ICRC . We discuss the proposed designs in .

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 when, and only when, they appear in all capitals, as shown here.

The Problem

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.

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.

Requirements The digital emblem's requirements were adapted from the ICRC's report on digital emblems . 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.

Covert Inspection A digital emblem MUST NOT reveal whether someone 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Proposed Designs for a Digital Emblem Two designs were proposed to solve the problem of a digital emblem. First, JHU APL proposed a DNS-based solution for a digital emblem . Second, CECYT (a joint endeavour between ETH Zurich and Bonn University) proposed An Authentic Digital EMblem (ADEM), which was initially described in an academic publication , but was also specified technically and has openly accessible, working prototypes (Go library and CLI, Browser extension). We focus here on ADEM as it was selected by the ICRC as the most suitable proposal for a digital emblem given its scope of applying emblems to digital assets and using the existing physical emblems for labeling physical assets. ADEM was designed following the requirements laid out in this draft. ADEM follows a decentralized trust model and utilizes existing infrastructure wherever possible, e.g., it provides accountability through the Certificate Transparency infrastructure . ADEM was designed to be distributed over many channels and as such is not bound to one mode of transportation. The academic paper foresees distribution of digital emblems via TLS, DNS, and UDP. Next to its prototype, ADEM's security was thoroughly evaluated and formal proofs of security are described in the academic publication. Once there is consensus on the scope of a digital emblem, the plan is to propose ADEM as a basis for designing a digital emblem. Although ADEM has gone through several iterations in collaboration with the ICRC, it is expected that it will be refined by the IETF WG that adopts it to ensure industry interoperability with good protocol practices. In particular, it must be investigated whether it fits the needs of all stakeholders of a digital emblem.

Considerations of Potential Risks Because digital emblems label digital infrastructure as legally protected, misuse of a digital emblem may not always be automatically detectable. In this section, we discuss two examples of potential misuse and how the section aims ensure that this standard is utilized responsibly. First, a nation state could misuse a digital emblem to wrongfully protect infrastructure used to enforce Internet censorship or shutdowns for its population. Second, technology vendors that provide online services or resources might maliciously or accidentally apply digital emblems to not only IHL-protected assets but their general infrastructure that hosts this and other services. In both cases, such misuse would abuse and potentially undermine combatants' and resistance movements' respect for IHL only to label one's own infrastructure, which even may actively harm human rights. In all cases where a digital emblem is deployed, it should be noted that verifying a digital emblem MAY include more than verifying its presence and authenticity. Verifiers MAY also observe other behavior of the emblem-bearing asset, applying heuristics to check whether its plausible that the asset displays a digital emblem. Additionally, we point out that digital emblem's mechanism of providing authentication additionally enables combatants to hold emblem-bearers accountable should misuse be detected.

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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Department of Computer Science, ETH Zurich Department of Computer Science, ETH Zurich ETH Zurich None ETH Zurich ICRC ICRC Australian Red Cross Australian Red Cross Johns Hopkins University Applied Physics Lab Packet Clearing House Packet Clearing House Brigham Young University Johns Hopkins University Applied Physics Lab International law defines a number of emblems, such as the blue helmets of United Nations peacekeeping forces, the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross, as indicative of special protections under the Geneva Conventions. Similar protections attach to journalists who wear "Press" protective emblems on the battlefield, under Article 79 of Protocol I of the Geneva Conventions and Resolution 2222 of the United Nations Security Council. The emblems of national governments and inter-governmental organizations protect diplomatic pouches, couriers, and envoys under the Vienna Convention on Diplomatic Relations. Other marks enjoy protections against mis-use under the Paris Convention, the Madrid Protocol, and the Trade-Related Aspects of Intellectual Property Rights. Such physical emblems have a number of weaknesses (e.g., no real-time evaluation of their authenticity) and do not translate to the digital realm. This document describes a digital emblem which addresses the shortcomings of the physical emblems and makes possible the indication of protections of digital assets under international law. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

Acknowledgments Parts of this draft are based on the initial academic publication describing the proposal ADEM: An Authentic Digital EMblem . Initial work on this project was funded by the Werner Siemens-Stiftung (WSS). We thank the WSS for their generous support.