1 Introduction

1.1 Background

Current armed conflicts are highly complex, because of the sheer number of parties involved: regular military forces, armed groups, peacekeeping forces, neutral parties such as journalists and non-governmental human-rights and aid organisations, civilians, refugees etc. Even though parties are opposing forces, or neutral organisations that do not want to show any affiliation, they do require to quickly and directly communicate to one or more other parties involved in the conflict in different situations.

This is not new. The white flag is the original internationally recognized protective sign of truce or ceasefire, and request for negotiation. A white flag signifies to all that an approaching negotiator is unarmed, with an intent to surrender or a desire to communicate.

This standard for a digital white flag protocol, the Whiteflag Protocol, provides a reliable means for both combatant and neutral parties in conflict zones to digitally communicate pre-defined signs and signals using blockchain technology. These sign and signals can also be used to communicate information about natural and man-made disasters, thus creating shared situational awareness beyond conflicts.

All in all, the protocol forms the basis for an neutral and open network, the Whiteflag Messaging Network, for trusted real-time messaging between parties in conflicts and disaster response.

1.2 Purpose

The purpose of the Whiteflag Protocol is to provide an open, real-time, trusted communication channel between any or all parties in conflict and disaster zones, without the requirement for a trusted third party or any specific software or system. It is the intention to provide a means of communication to be used that is fast, reliable and accessible by everyone, in addition to internal communications within organisations and in addition to any currently existing but limited communication methods such as flags, signs, registers etc.

The purpose of this document is to describe and define the protocol and the message format of the communication channel for policy makers and specialists to be able to adopt and implement the Whiteflag Protocol.

1.3 Document Structure

Chapter 1 “Introduction” describes this document. Chapter 2 “Overview” defines the scope and gives an overview of the protocol, followed by typical use case examples in Chapter 3 “Use Case Examples”. Chapter 4 “Message Format” provides the detailed messages descriptions, and Chapter 5 “Protocol” the detailed protocol description.

1.4 Used Terminology

The following phrases in this specification must be interpreted as follows:

• … MUST: indicates that something is mandatory, i.e. an absolute requirement

• … MUST BE … IF …: indicates that something is mandatory if some condition is met

• … MUST BE … WHEN …: indicates something is mandatory when something becomes true

• … MUST NOT …: indicates that something is not allowed, i.e. an absolute prohibition

• … MAY ONLY … IF …: indicates something is only allowed if some condition is met

• … MAY …: indicates that something is allowed

• … SHOULD: indicates something is strongly recommended

• … SHOULD NOT: indicates something is strongly not recommended

• … NEED NOT … / … NOT REQUIRED : indicates that something is not mandatory

An overview of definitions of the most important terms used in this document can be found in Annex D.

1.5 License and Usage

All persons and organisations that contributed to the initial development of the Whiteflag Protocol did so disinterestedly.

The Whiteflag Protocol specification is dedicated to the public domain under the Creative Commons CC0-1.0 Universal Public Domain Dedication statement, meaning that to the extent possible under law, the authors and their organisations have waived all copyright and related or neighboring rights to this work, allowing anyone to copy, modify, distribute and implement the work, even for commercial purposes, all without asking permission.

In no way are the patent or trademark rights of any person affected by this dedication to the public domain, nor are the rights that other persons may have in the work or in how the work is used, such as publicity or privacy rights. Unless expressly stated otherwise, the authors and their organisations make no warranties about the work, and disclaim liability for all uses of the work, to the fullest extent permitted by applicable law. When using or citing the work, you should not imply endorsement by the authors or the affirmer.

WARNING: THE USAGE OF SIGNS AND SIGNALS IN THIS SPECIFICATION IS SUBJECT TO LOCAL AND/OR INTERNATIONAL LAWS. Please take note of the following when implementing or using this standard:

• This standard only specifies an additional means of communication for certain signs and signals, and it does not replace any existing standard, regulation or means of communication, whether mandatory or not, including but not limited to physical signs, radio communications, official registers, etc.

• The usage of protective signs is subject to International Humanitarian Law. Misuse of protective signs is a punishable violation under local and international laws.

• The usage of emergency signals may be subject to various regulations and standards, depending on location and context. The misuse of emergency signals, including misuse of the duress functionality, may be a punishable violation under local and international laws.

1.6 Configuration Control

It is foreseen that this standard requires updates in the near future as a result of validation testing and to ensure compatibility with emerging distributed computing practices, paradigms and standards. Therefore, for the time being, the standard will remain under configuration control of the authors. Requests and comments may be e-mailed to the authors:

• T. Schless: tschless (at) acm . org
• M. Kolenbrander: mkolenbrander (at) acm . org

In the meantime, a more sustainable process for configuration control of this standard in line with its open character is under consideration.

2 Overview

2.1 Design Principles

The following principles are the basis for the Whiteflag Protocol:

• the protocol is based on blockchain technology, but is “blockchain-agnostic”, i.e. independent of any specific blockchain;
• the protocol is as free and open as the underlying blockchain and internet technologies are: anyone can join at any time without permission;
• the working of the protocol does not rely on any third party, i.e. there is no ownership of the network that is created with the protocol and no dependency on specific software or a system;
• the protocol does not have access control, but does provide means of authentication;
• the protocol inherits the data integrity and non-repudiation properties of the underlying blockchain(s);
• the protocol allows to use encryption for message confidentiality;
• the protocol should be compliant with international rules and standards for armed conflicts;
• the protocol is kept as simple as possible, to ensure easy access, easy understanding and easy implementation;
• the message formats are fixed to ensure interoperability and a common understanding between the communicating parties;
• the protocol is extensible to allow functionality to be added with backwards compatibility;
• implementation only requires the use of open standards.

2.2 Protocol Stack and Scope

The Whiteflag Protocol works on top of the internet and on one or more blockchains to create a network for trusted communications that can be used by different applications through application programming interfaces.

The protocol stack comprises the following 6 layers, from bottom to top:

• The Connection Layers are to ensure global connectivity. Essentially these are the 7 OSI layers as implemented with the Internet.

• The Blockchain Layer ensures connectivity and interaction with specific blockchains, typically through their APIs.

• The Blockchain Overlay Network Layer is an abstraction for applications using existing blockchains to validate their transactions. In this case, the Whiteflag Messaging Network is created as a blockchain overlay network by Whiteflag applications encapsulating Whiteflag messages in blockchain transactions.

• The Decentralised Protocol Layer is a protocol that is not controlled by a single entity. That is exactly what the Whiteflag Protocol and the scope of this specification is.

• The Application Programming Interface (API) layer contains the solutions that allow software to interface with the Whiteflag Protocol. These APIs may provide useful additions to the protocol such as handling, tracking and searching of Whiteflag messages.

• The Application Layer is the part of the stack that comprises the applications that are actually used by the end-uses. These might be existing classical applications such as databases in use by various organisations, or newly developed web applications or smartphone apps that can send, receive, filter, analyse messages.

2.3 References

2.3.1 International Rules & Regulations

2.3.1.1 International Humanitarian Law

A. Convention (IV) respecting the Laws and Customs of War on Land and its annex: Regulations concerning the Laws and Customs of War on Land. The Hague, 18 October 1907.

B. Convention (I) for the Amelioration of the Condition of the Wounded and Sick in Armed Forces in the Field. Geneva, 12 August 1949.

C. Protocol additional to the Geneva Conventions of 12 August 1949, and relating to the Adoption of an Additional Distinctive Emblem (Protocol III), 8 December 2005.

D. Convention (III) relative to the Treatment of Prisoners of War. Geneva, 12 August 1949.

E. Convention (IV) relative to the Protection of Civilian Persons in Time of War. Geneva, 12 August 1949.

F. Protocol Additional to the Geneva Conventions of 12 August 1949, and relating to the Protection of Victims of International Armed Conflicts (Protocol I), 8 June 1977.

G. Convention on the Safety of United Nations and Associated Personnel. New York, 9 December 1994.

H. Treaty on the Protection of Artistic and Scientific Institutions and Historic Monuments (Roerich Pact). Washington, 15 April 1935.

I. The 1954 Hague Convention for the Protection of Cultural Property in the Event of Armed Conflict and its two (1954 and 1999) Protocols, United Nations Educational, Scientific and Cultural Organization (UNESCO).

2.3.1.2 International Standards

J. IMO IA994E International Code of Signals, 2005 Edition.

K. Disaster Category Classification and peril Terminology for Operational Purposes, Centre for Research on the Epidemiology of Disasters (CRED) and Munich Reinsurance Company (Munich RE), October 2009.

L. Economic Infrastucture Common Reporting Standard Codes, Organisation for Economic Cooperation and Development (OECD).

2.3.2 Technical Standards

2.3.2.1 Communication and Data Format Standards

M. RFC 3339, Date and Time on the Internet: Timestamps, July 2002, internet: https://www.ietf.org/rfc/rfc3339.txt

N. RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, internet: https://www.ietf.org/rfc/rfc3986.txt

O. RFC 4627, The application/json Media Type for JavaScript Object Notation (JSON), July 2006, internet: https://www.ietf.org/rfc/rfc4627.txt

P. RFC 7515, JSON Web Signature (JWS), May 2015, internet: https://www.ietf.org/rfc/rfc7515.txt

Q. ISO 8601, Date and Time Representation

R. ISO 6709, Standard representation of geographic point location by coordinates

2.3.2.2 Cryptographic Standards

S. OpenSSL Implementation of the Elliptic Curve Diffie-Hellman (ECDH) algorithm, internet: https://wiki.openssl.org/index.php?title=Elliptic_Curve_Diffie_Hellman&oldid=1558

T. OpenSSL Implementation of the Advanced Encryption Standard (AES)

U. RFC 5639, ECC Brainpool Standard Curves & Curve Generation, March 2010, internet: https://www.ietf.org/rfc/rfc5639.txt

V. RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function (HKDF), internet: https://www.rfc-editor.org/rfc/rfc5869.txt

2.4 High-level Functional Overview

2.4.1 Blockchain and Communication Functionality

2.4.1.1 General

A blockchain is a distributed database that maintains a continuously-growing list of ordered records called blocks, each containing a timestamp and a hash-based link to a previous block going all the way back to the genesis block. Blockchains are distributed computing systems with high byzantine fault tolerance: secure by design and inherently resistant to modification of the data; once recorded, the data in a block cannot be altered retroactively.

Therefore, a blockchain can be seen as an open, distributed ledger that can record transactions between parties efficiently and in a verifiable and permanent way. This makes blockchains very suitable for the recording of events and messages.

The Whiteflag Protocol is not a blockchain in itself. It defines the messages for signs and signals used in armed conflicts and for disasters, and it defines how those messages can be send as transactions on, in principle, any blockchain. Possibly, even other related distributed computing and networking technologies may be usable, depending on the characteristics.

The usage of the Whiteflag Protocol on one or more specific blockchains, establishes what in this specification is called the Whiteflag Messaging Network, or just “the network”, and can be seen as what is sometimes called a Blockchain Overlay Network.

Please note that the Whiteflag Protocol is specifically designed to use public blockchain systems. Private blockchain systems, or permissioned distributed ledger systems, do not conform to the design principles of the Whiteflag Messaging Network, as these systems require a trusted party (master nodes) for consensus in the network.

2.4.1.2 Originator and Account

The originator is a specific person or organisation that sends Whiteflag Messages on the Whiteflag Messaging Network. The originator’s identity is established upon initial entry to the network. An originator may use multiple accounts on the blockchain. Although an account may use multiple (deterministic) addresses, the usage of more than one address by a single account is not recommended for Whiteflag.

It is only required for an originator to provide identity information before sending messages; it is not required to provide identity information to receive messages, as anyone can observe what is happening on the blockchain.

Blockchain networks using digital signature schemes that provide fully anonymous transactions could theoretically be used to anonymously send messages on the Whiteflag Messaging Network. Examples of such blockchains are ZCash and Monero, which use zero-knowledge-proofs and ring signatures respectively to create conditions of untraceability and unlinkability. These type of blockchains do not conform to the principles of this standard, and should therefore not be used.

2.4.1.3 Authentication mechanisms

An originator must introduce itself on the Whiteflag Messaging Network and provide identity information with one or more initial authentication messages. An initial authentication message contains the self-chosen name of the originator, and a method to verify that the originator’s blockchain address is under control by the person or organisation the originator claims he is.

Currently, two basic methods of verification are supported by the protocol.

1. The first method makes use of an internet resource, such as a web site, under control of the originator. The initial authentication message of the originator contains an Uniform Resource Locator (URL) to the internet resource, where the originator posts the corresponding blockchain address, along with its proclaimed name, both signed with a digital signature using the address’ secret private key. Anyone can now validate that the blockchain address is under control by the originator by performing a check on the validity of the digitally signed message using the blockchain address’ public key. This verification method assumes that the originator is in control of the internet resource specified in the initial authentication message, and can therefore be associated with that internet resource. As a result, the initial trustworthiness of the identity is as strong as the internet resource being used: obviously this differs between an SSL-secured web site of an acclaimed organisation and for instance a pseudonymous social media post. Although an internet site is vulnerable to being compromised and an attacker could alter the authentication data on the internet resource, this will never result in a valid digital signature as long as the private key remains secret.

2. The second method uses a pre-shared token. The originator and a receiver exchange a token, which is not known to anybody else until the originator identifies himself by putting the token in the initial authentication message. The receiver can verify now that the claimed blockchain address actually belongs to the originator who was in prior possession of the token. The originator may do this multiple times with different tokens and/or different receivers.

The initial authentication can be enhanced by using multiple initial authentication messages, i.e. by combining both verification methods, and also use multiple tokens and URLs. Additionally, the protocol allows other participants to confirm the originator’s identity, which is especially useful if those confirming participants have well-established identities.

For blockchains that encourage or require to use a different address for each transaction, deterministic key chains are used to link the authentication message both to the blockchain account as well as to other messages sent by the same originator but with different addresses.

The authentication mechanism is described in detail in Management Messages: (initial authentication message) and Joining and Leaving the Whiteflag Network (protocol for initial authentication). After initial authentication, the Whiteflag Protocol utilizes the authentication mechanism of the underlying blockchain.

As means for digital identification on the internet are still evolving, it is anticipated that additional methods will be added in future versions.

2.4.1.4 Communications Security

The Whiteflag Protocol leverages blockchain technology to ensure authentication, data integrity and non-repudiation. The blockchains ensures that any message ever sent will be verifiable, unalterable and available to anybody, even to participants that start to use the protocol later in time.

In blockchain systems, an electronic token (often called a coin) is defined as a chain of digital signatures. These tokens are constructed of input and output channels, which can be used to include data in a transaction. An owner transfers a token to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the token. A sender can verify the signatures to verify the chain of ownership.

Public blockchain networks using the proof-of-work consensus model (Nakamoto consensus) timestamp transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The timestamp proves that the data must have existed at the time in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Blockchain networks using a different consensus model (such as proof-of-stake) are currently in an experimental phase and have not yet been proven to work securely at large scale. At this point, it is not advised to use any other type of public blockchain system than those using a proof-of-work based consensus model.

Nodes can leave and rejoin the blockchain and thus the Whiteflag Network at will, accepting the proof-of-work chain as validation of what happened while they were gone. Upon rejoining, missing blocks are downloaded, verified and added to the nodes’ local copy of the database until it has caught up with the network and is in sync (again).

The hash chain of blocks provides an unchangeable historical record, which is verifiable to anyone and goes all the way back to the first block ever created by the network.

2.4.1.5 Data Security

Even though the Whiteflag Protocol is not designed with message confidentiality specifically in mind, the protocol does allow encryption for message confidentiality by defining the means to optionally encrypt the message contents. This is described in detail in 4.1.4.

The Whiteflag Protocol does not specify how the encryption keys should be managed or distributed. It is between the originator and recipient to agree on the encryption method and key exchange.

2.4.2 Message functionality

2.4.2.1 Functional Messages

The following Functional Messages are specified in this standard. These messages are to send a sign or signal as defined in international standards, and to provide additional information.

A specific Functional Message has a single meaning. For example, a Danger Sign is just that: a Danger Sign, which does not imply that the originator is in danger or requires assistance. In such a case, the originator must send an emergency signal.

However, a Functional Message may be related to an earlier Functional Message by referencing it. In this way, sequences of message can be created, e.g. for moving objects (by updating the coordinates of a Protective Sign), or requesting assistance for an object under attack (by sending an Emergency Signal referring to a Status Signal referring to a Danger Sign). Message sequencing is described in detail in Message Sequences.

2.4.2.2 Management Messages

A number of Management Messages are defined to provide additional means to verify the validity of the blockchain address and related account, to support cryptographic functions and to test connectivity and functionality.

2.4.2.3 Duress Indicator

The Whiteflag Protocol provides duress functionality, i.e. an indicator that a message has been sent under (threat of) violence, or other pressure and should therefore be interpreted with caution.

This functionality is especially useful for implementations of the protocol in devices used by workers and operators in the field, where there is a higher risk of hijacking and kidnapping resulting in possible misuse of the Whiteflag communication from an address of that account.

This standard only specifies how the duress indication is to be implemented in the protocol and how it should be interpreted. The way the Duress Indicator will be triggered by a Whiteflag capable application or device, is outside the scope of this standard, because this can be implemented in many different ways to suit different scenarios and requirements.

2.4.3 Spatial information

Signs and signals about structures and areas may contain spatial information. The Whiteflag protocol uses the EPSG:4326/WGS84 geodetic coordinate system. The protocol does (currently) not allow to provide height and altitude information, and therefore can only be used to locate objects on the earth’s surface.

Structures and areas can be represented using a limited number of geometric shapes: circles, rectangles and isosceles triangles, and any combination of these.

The real-world structure or area must be fully contained by the geometric shapes representing it. The centre of a geometric shape is determined by the location specified in the Whiteflag message. The orientation of the shape is the angle between a virtual north oriented vector, and the first specified dimension of the shape: this is one of the sides for a rectangle, and the height for an isosceles triangle; a circle does not have an orientation.

2.5 Minimum Implementation

When implementing this standard, it is not required to implement it in its entirety. However, any implementation of the Whiteflag Protocol that sends messages on the network, must implement at a minimum the following functionality:

• the A message with at least one authentication option;
• the possibility to Recall, Update and Discontinue (Reference Codes 1, 2 and 4) any implemented sign or signal, if such Reference Type is valid i.a.w. Reference options.

Also, for both senders and receivers, it is required that any part of this standard that is implemented complies with this standard.

2.6 Implementation Considerations

This paragraph addresses a number of aspects that are technically not part of the standard, but require consideration or are good practices for an interoperable and secure implementation of the Whiteflag protocol.

2.6.1 Trustworthiness of information

The Whiteflag Protocol provides a trusted communication channel in the sense that the originator is authenticated, that messages cannot not be altered or disappear once recorded, all without the requirement of a trusted third party.

However, it is important to understand that a trusted communication channel does not in any way guarantee that the information in a message is true. Upon reception of a Whiteflag message, it is up to the receiver to assess the credibility of the information sent.

Nevertheless, the characteristics of the protocol do help in evaluating the credibility of information:

• The protocol ensures instant verification of the originator. Therefore, if a source is a priori considered reliable by the recipient (which will be often the case for NGOs, journalists, UN peacekeepers, UNMAS, civil authorities, etc.), the information can be considered to have a high level of credibility.

• The protocol allows information to be confirmed by another message of a different originator, and therefore facilitates confirmation of the same information by multiple sources.

• The protocol provides duress functionality;

• Since all information is persistent, this allows for evaluating the reliability of a source over time by cross-checking facts in retrospect.

A recipient may use the following levels of reliability of a source and credibility of information:

Also note that the protocol does not require all messages to be processed by a recipient. A recipient may choose to ignore unknown addresses and accounts, to blacklist unreliable addresses and accounts, to filter messages about an object outside a certain area of interest, create custom perspectives, merge information with other sources, etc. etc.

2.6.2 Account and Private Key Protection

The protocol does not state a mandatory blockchain account and private key protection setup. There are however several important guidelines to consider:

• Third party hosts should not be used to create accounts on a blockchain, because the identity of the sender should be directly linked to the account. Using a third party to create an account creates attack vectors by which an account could be compromised.
• Public blockchains provide free, open source clients that facilitate the creation of accounts without any third party involved. It is good practice to protect your account by implementing security measures on machines and devices under your own control or supervision.
• Third party hosts should not be used host to store private keys. Storing the secret key outside your control or under supervision creates attack vectors by which an account could be compromised.
• To protect private keys from theft, hardware wallets, secure processing units and cold wallets should be used when possible.
• To protect an account from being compromised, multi-factor authentication as well as multi-signature accounts should be used when possible.
• If account and/or related addresses need to be permanently de-activated, simply delete the private key(s), and, if possible, send an A(4) message.

2.6.3 Encryption and Key Exchange

The protocol provides the option to encrypt a message for confidentiality. However, this standard provides the minimum functionality required for one interoperable encryption and key management mechanism. Please note that the security of encryption relies largely on the actual implementations.

If there is a reason to use encryption, do note that all messages are persistent on the blockchain and it should be assumed that at some point in the future messages can and will be decrypted. Therefore, only use dedicated keys, and only encrypt information that is time-sensitive, i.e. information that will not be valid or relevant anymore over time, such as the status or the location of a moving object.

When using encryption, a number of considerations should be taken into account. Obviously, a secure encryption algorithm suitable for relatively short strings should be used. Also, do take into account that even if messages are encrypted, information may leak through usage patterns. Therefore, do not use the same blockchain addressed and the same proof-of-identity for both encrypted and unencrypted messages.

2.6.4 Processing and Storage of Messages

On the Whiteflag Network, messages must be formatted and processed as indicated in this standard. Additionally, this standard defines how messages and message sequences should semantically interpreted.

To help implementing and validating Whiteflag Messages, Annex B provides a JSON schema that describes the messages, which might be of beneficial use for application developers.

However, strictly speaking, this schema is outside the scope of this standard: firstly because the Whiteflag Messages sent on the network are not JSON-formatted, and secondly because this standard does deliberately not specify how messages are to be processed and stored by applications (an application might very well use XML instead of JSON). Nevertheless, it is recommended to use a JSON format compliant with this schema for open APIs.

2.7 Note on the notation of Messages and Message Sequences

For documentation and software development purposes, messages codes and message sequences might be written as follows:

• a message may be referred to by its message code, e.g. T for a test message;
• a specific sign or signal may be indicated by the combination of message and subject code, e.g. E01 for a distress signal;
• a reference indicator may be written in between brackets after the message code, e.g. A(2) for an update to an earlier A message;
• an encrypted message is written between square brackets, e.g. [Q(0)14];
• the originator may be indicated behind the message code and reference indicator, e.g. A(0)X is an original authentication message from X;
• the symbol < is used as a pointer in the message sequence; the symbol is repeated to indicate to which message is referred, e.g. << means two messages before.

For example, a message from originator X for relating an area under attack to an existing protective sign from a hospital H may be written as P31(0)H < D10(5)X. When the attack ends and the status of the hospital is provided, the full sequence will read: P31(0)H < D10(5)X < D10(4)X <<< S23(5)H.

3 Use Case Examples

(moved to Annex F)

4 Message Format

4.1 Message Structure

4.1.1 Representations

A Whiteflag message can have different representations at different levels of the protocol stack:

• at the Blockchain Overlay Network Layer (i.e. the level at which the Whiteflag Messaging Network is established) the message is represented as a compressed binary string, and optionally encrypted;
• at the Decentralised Protocol Layer, a message is represented as an uncompressed and unencrypted concatenated character string comprised of the message fields;
• at the API layer, a message and its message fields can have any appropriate representation using a structured language, such as JSON or XML;

The standard describes the uncompressed and unencrypted concatenated character string at the Decentralised Protocol Layer, and how these messages are compressed into a binary string, and optionally encrypted.

4.1.2 Encoding

An uncompressed and unencrypted Whiteflag Message consists of:

• the Message Header (described in Message Header), which is the same for all messages and consists of 7 fields with a total length of 71 bytes;
• the Message Body (described in Message Body), of which the fields and number of bytes per field differ between message types, and is therefore variable in length.

The individual bytes of an uncompressed and unencrypted messages are encoded using a single 7-bit/1-byte UTF-8 code unit, allowing the usage of UTF-8/Unicode code points U+0000 through U+007F, which are identical to the first 128 characters of the ASCII-set.

Depending on the usage of the field, not all characters/code points are allowed for each field. The field descriptions of the message header and body in in Message Header and Message Body, use the following characters to indicate which subset of characters is valid:

• c indicates any valid 1 byte UTF-8/Unicode character, i.e. UTF-8 code points U+0000 through U+007F;

• a indicates that any alpha-numeric character (0-1, A-Z, a-z), i.e. UTF-8 code points U+0030 trough U+0039, U+0041 through U+005A, and U+0061 through U+007A;

• b indicates that only a binary character (0-1) is the be used, i.e. UTF-8 code points U+0030 trough U+0031;

• d indicates that only a decimal character (0-9) is to be used, i.e. UTF-8 code points U+0030 trough U+0039;

• x indicates that only a hexadecimal character (0-F) is to be used, i.e. UTF-8 code points U+0030 trough U+0039, and U+0041 trough U+0046.

Instead of d, the letters y, m, d, h, m, and s are used in some field descriptions in and Message Body to indicate digits representing years, minutes, days, degrees, hours, minutes and seconds respectively. Syntactically they are the same as a decimal character indicated with a d, and therefore encoded and compressed in the same way, but semantically they are different.

Capitals used in the field format descriptions of the message header and body in Message Header and Message Body, including capitals of the above, indicate that such a character is to be used literally.

Before the message is embedded in a blockchain transaction, the message is compressed and optionally encrypted as described below.

4.1.3 Compression

Whiteflag messages must be compressed to allow usage on blockchains with limited space for custom information, and to improve optional encryption. Compression of the message is done as follows:

• all fixed characters are omitted, except for the Prefix field;

• binary characters (b), binary indicators and number signs are compressed to 1 bit;

• decimal and hexadecimal characters (d and h) are compressed to a half-byte (4 bits) unsigned binary coded decimal/hexadecimal.

The descriptions of the message header and body in in Message Header and Message Body, show how the compression must be applied to each field.

4.1.4 Encryption

The third field of the message is an indicator for which encryption is being used. This standard currently only provides limited support for encryption, but allows implementation specific encryption mechanisms.

If encryption is used, the whole message must be encrypted, except for the Prefix, Version and EncryptionIndicator, which must never be encrypted.

Note that, depending on the encryption algorithm used, the resulting length of the message may differ from the unencrypted message length, which may complicate the embedding of the message in a transaction on certain blockchains.

4.1.5 Embedding

To finally send the message, after compression and encryption, the message is embedded in a blockchain transaction. How the message is embedded in the transaction depends on the blockchain and is specified in Annex A.

4.2 Message Header

4.2.1 Generic Message Header

All messages use the same generic message header, specified below.

4.2.1.1 Generic Message Header Fields

4.2.1.2 Prefix Field

The Prefix field is a fixed value field to easily identify Whiteflag Messages on the blockchain. The filed must contain two 1-byte UTF-8 encoded characters WF.

4.2.1.3 Version Field

The Version field indicates which version of the standard is used as the specification for the message. For implementations based on this version of the specification, the field must be a 1-byte UTF-8 encoded character 1.

4.2.1.4 Encryption Indicator Field

The EncryptionIndicator field specifies how if and how a message is encrypted for confidentiality. The contents of the field must be a 1-byte UTF-8 encoded alpha-numeric character i.a.w. the following table.

4.2.1.5 Duress Indicator Field

The DuressIndicator field value must be 0, unless the sign or signal was sent under threat or force. In that case the DuressIndicator field must be 1.

See Duress Indicator for further considerations on the duress functionality.

4.2.1.6 Message Code Field

The MessageCode field specifies the message type. The contents of the field must be a 1 byte UTF-8 encoded alpha-numeric character value corresponding with a message type defined in this specification.

A message with an invalid, i.e. undefined, message code, must be ignored.

4.2.1.7 Reference Indicator Field

The ReferenceIndicator field specifies how a message relates to an earlier message. The contents of the field must be a 1-byte UTF-8 encoded value from the following table.

A message with a Reference Indicator that does not comply with these rules must be ignored. However, a recipient may use non-compliant messages to evaluate the reliability of the originator.

By referencing other messages, message sequences can be created. However, not every message type and reference type may reference every other message type and reference type. The rules for referencing and functionality of message sequences are specified in detail in Referencing Messages and Message Sequences.

4.2.1.8 Referenced Message Field

The ReferencedMessage field is a 64-byte UTF-8 encoded string containing a unique hexadecimal identifier of the referenced message. This allows for referencing a 256-bit hash. Since other messages can only be identified using the transaction identifier of the underlying blockchain, the identifier depends on the underlying blockchain. If the underlying blockchain uses a hash larger than 256 bits, the first 256 bits of the hash should be used. The transaction identifiers of the most common blockchains are shown in Annex A.

If the ReferenceIndicator field is 0, the ReferencedMessage field must be ignored by the receiver. This allows the field to be filled with a random 64-byte UTF-8 encoded hexadecimal string, e.g. to prevent a large part of the message to be all zeros when encrypting it.

4.3 Message Body

4.3.1 Functional Messages: Signs & Signals

4.3.1.1 Signs & Signals Message Fields

The message body of functional messages representing a sign (message types P, D and I) or a signal (message types E, S, M and Q), must contain the following fields:

In addition, the message body of message type Q may be extended with the following fields:

These fields may be repeated for additional objects for which the request is made, e.g. bytes 139-142 may contain additional ObjectType2 and ObjectType2Quant fields, etc.

4.3.1.2 Subject Code Field

The SubjectCode field defines the actual sign or signal, and must be 2-byte UTF-8 encoded value from the following tables with subject codes for each sign/signal message type below. Common official and/or visual equivalents for the defined signs and signals are shown in Annex E.

4.3.1.2.1 Protective Signs

References: P01-03: i.a.w. Convention (IV) respecting the Laws and Customs of War on Land and its annex: Regulations concerning the Laws and Customs of War on Land. The Hague, 18 October 1907 P11-12: Convention (I) for the Amelioration of the Condition of the Wounded and Sick in Armed Forces in the Field. Geneva, 12 August 1949. P13: Protocol additional to the Geneva Conventions of 12 August 1949, and relating to the Adoption of an Additional Distinctive Emblem (Protocol III), 8 December 2005. P20: Convention on the Safety of United Nations and Associated Personnel. New York, 9 December 1994. P31: Convention (IV) relative to the Protection of Civilian Persons in Time of War. Geneva, 12 August 1949 P32-33: Convention (III) relative to the Treatment of Prisoners of War. Geneva, 12 August 1949. P51: Treaty on the Protection of Artistic and Scientific Institutions and Historic Monuments (Roerich Pact). Washington, 15 April 1935 P52-53: The 1954 Hague Convention for the Protection of Cultural Property in the Event of Armed Conflict and its two (1954 and 1999) Protocols, United Nations Educational, Scientific and Cultural Organization (UNESCO) P60: Protocol Additional to the Geneva Conventions of 12 August 1949, and relating to the Protection of Victims of International Armed Conflicts (Protocol I), 8 June 1977.

4.3.1.2.2 Emergency Signals

4.3.1.2.3 Danger & Disaster Signs

4.3.1.2.4 Status Signals

4.3.1.2.5 Infrastructure Signs

4.3.1.2.6 Mission Signals

4.3.1.2.7 Request Signals

4.3.1.3 DateTime Field

The DateTime field must contain the moment in time using from when the sign or signal is valid, using Coordinated Universal Time (UTC).

This timestamp need not to be identical to the timestamp of the blockchain transaction of the message: the sign or signal may be valid from an earlier or future point in time and may therefore be earlier or later than the timestamp of the blockchain transaction.

Based on ISO 8601 and RFC 3339, the DateTime field must be formatted as follows: YYYY-MM-DDThh:mm:ssZ, where:

• yyyy are 4 digits for the calendar year

• mm are 2 digits for the number of the month; valid values are: 01-12

• dd are 2 digits for the day of the month using; valid values are: 01-31

• hh are 2 digits for the hour of day; valid values are: 00-23

• mm are 2 digits for the minutes; valid values are: 00-59

• ss are 2 digits for the seconds; valid values are: 00-60 (including a possible leap second)

• Z is literally the character “Z”, indicating UTC.

A message with an invalid DateTime field must be ignored.

4.3.1.4 Duration Field

The Duration field may contain the time-period for how long the sign or signal is valid counted from the date and time in the DateTime field. A sign or signal may be valid for a definite period with a maximum of 99 days 23 hours and 59 minutes, or a minimum of 01 minute, or for an indefinite period.

Based on ISO 8601, the Duration field must be formatted as follows: PnnDnnHnnM (i.e. regular expression \^P\[0-9\]{2}D\[0-9\]{2}H\[0-9\]{2}M\$), where:

• P is literally the character “P”, indicating that the string represents a period

• nn are 2 digits for the number of days; valid values are: 00-99

• D is literally the character “D”, indicating the previous digits represent the number of days

• nn are 2 digits for the number of hours; valid values are: 00-23

• H is literally the character “H”, indicating the previous digits represents the number of hours

• nn are 2 digits for the number of days; valid values are: 00-59

• M is literally the character “M”, indicating the previous digits represents the number of minutes

For a sign/signal to be valid for an indefinite period, the duration must be set to 0 as follows: P00D00H00M.

A message with an invalid Duration field must be ignored.

4.3.1.5 Object Type Field

The ObjectType field contains a hexadecimal code to indicate to what sort of object the sign or signal applies to. This information is optional and must be set to 00 if not used. However, it is encouraged to use it, because it might be valuable for the receiver(s) of the message.

The table below shows which object types may be used for which message subjects, and which combinations types are not allowed.

4.3.1.6 Object Location Fields

The ObjectLatitude and ObjectLongitude fields specify the location of the centre of the object on, or projected on, the earth’s surface in decimal degrees latitude and decimal degrees longitude, using the WGS84 datum (i.e. EPSG:4326). The vertical location (height or depth) cannot be provided.

Based on ISO 6709 - Standard representation of geographic point location by coordinates, the ObjectLatitude fields must be formatted as follows: \_dd.ddddd (i.e. regular expression \^\[+-\]\[0-9\]{2}\\.\[0-9\]{5}\$), where:

• The digits represent the north-south longitude; valid values are: -90.00000 to +90.00000

• \_ is either + or - to denote north (+) or south (-).

Based on ISO 6709 - Standard representation of geographic point location by coordinates, the ObjectLongitude fields must be formatted as follows: \_ddd.ddddd (i.e. regular expression \^\[+-\]\[0-9\]{3}\\.\[0-9\]{5}\$), where:

• The digits represent the east-west latitude; valid values are: -180.00000 to +180.00000

• \_ is either + or - to denote east (+) or west (-).

The object location must be specified for Protective Signs and Danger Signs (Message Codes P and D).

The object location may be used for Emergency Signals and Status Signals (Message Codes E and S), e.g. for security reasons. If the object location is omitted, the coordinates must be set to the following value: +99.99999+999.99999.

The object location may not be omitted in a Status Signal (Message Code S) referencing a Protective Sign or a Danger Sign (Message Code P or D).

4.3.1.7 Object Size Fields

The ObjectSizeDim1 and ObjectSizeDim2 fields may be used to specify the horizontal surface dimensions of areas and structures in meters. Valid values are: 0001 to 9999. The value of a dimension that is omitted, must be set to 0000.

For (groups of) persons (Object Codes 10-1F), the Object Size may be provided. The Object Size represents the area in which the person(s) is/are located. The area must be defined as small as possible.

For shaped areas and structures (Object Codes 21-2F and 31-3F), the Object Size must be provided. For unspecified areas and structures (Object Codes 20 and 30) the dimensions are by definition unknown, and must be omitted. For all other objects, the Object Size must be omitted.

For circle shaped areas and structures (Object Codes 21 and 31), the ObjectSizeDim1 field represents the radius; the ObjectSizeDim2 field has no meaning for circle shaped areas and structures and must be omitted.

For rectangle shaped areas and structures (Object Codes 22 and 32), the ObjectSizeDim1 field represents the length of the side for which the orientation is specified with the Object Orientation Field; the ObjectSizeDim2 field represents the other side.

Triangle shaped areas and structures (Object Codes 23 and 33) are isosceles triangles, with the ObjectSizeDim1 field representing the triangle height and the ObjectSizeDim2 represents the base.

4.3.1.8 Object Orientation Field

The ObjectOrientation field may be used to specify the orientation of the object in decimal degrees, where 000 means North.

Valid values are: 000 to 359. If the object’s orientation is omitted, the field value must be set to 999.

If an Object Size is specified using the ObjectSizeDim1 and ObjectSizeDim2 fields, then the ObjectOrientation field must be specified as well. If the Object Size is not specified, then the Object Orientation must be omitted.

4.3.1.9 Object Request Fields

The object request fields ObjectType* and ObjectType*Quant may only be used in Q messages and must be used together, with the object type field before the quantity field.

These fields may be repeated up to seven (7) times, giving a maximum of eight (8) objects with their respective quantity.

The ObjectType* field contains a hexadecimal code to indicate what sort of object the request applies to. The values correspond with those of the ObjectType field as specified in 4.3.1.5, with the following restrictions:

• when referring to persons, the exact number of person must be specified and therefore the 12-1F may not be used;

• unmovable objects, i.e. 20-2F areas and 30-3F structures,may not be used.

Note that in accordance with 4.3.1.5, the object code of a Q message itself must represent an area, i.e. code 20-2F.

Valid values for an ObjectType*Quant field are 00 to 99. If the quantity of an object is unknown, then the respective ObjectType*Quant field must be 00.

4.3.2 Functional Messages: Reference

4.3.2.1 Reference Message Fields

4.3.2.2 Reference Method Field

The ReferenceMethod field defines the mechanism for reference. The field must be 1-byte UTF-8 encoded hexadecimal character. Currently only one reference method has been defined:

4.3.2.3 Reference Data Field

The content of the ReferenceData field depends on the reference method:

• If the ReferenceMethod method indicates a reference to an internet resource (reference method1), then the VerificationData field must contain a valid URL.

The ReferenceData field may be longer than 40 bytes, if allowed by underlying blockchain. If the length of the ReferenceData field is insufficient to provide the complete URL, an additional Reference Message may be sent with the rest of the URL using reference code 3.

4.3.3 Functional Messages: Free Text

4.3.3.1 Free Text Message Fields

4.3.3.2 Text Field

The Text field can be used to send 40x 1-byte UTF-8 encoded text, typically to provide additional information about a sign or signal, using reference code 3 or 5.

The Text field may be longer than 40 bytes, if allowed by underlying blockchain. If the length of the Text field is insufficient to provide all text, an additional text message may be sent using reference code 3.

4.3.4 Management Messages: Authentication

4.3.4.1 Authentication Message Fields

The message body of management messages for (initial) authentication (message type A), must contain the following fields:

4.3.4.2 Verification Method Field

The VerificationMethod field defines the mechanism for authentication of the blockchain address and related account, and must be a 1-byte UTF-8 encoded hexadecimal character from the following table with codes for each verification method:

4.3.4.3 Verification Data Field

The content of the VerificationData field depends on the verification method:

• If the InternetResource method is specified (verification method 1), then the VerificationData field must contain a valid URL;

• If the SharedToken method is specified (verification method 2), then the VerificationData field must contain the verification token.

The VerificationData field may be longer than 40 bytes, if allowed by underlying blockchain. If the length of the VerificationData field is insufficient to provide the complete URL or verification token, an additional Authentication Message may be sent with the rest of the URL or verification token using reference code 3.

4.3.5 Management Messages: Cryptographic Support

4.3.5.1 Cryptographic Support Message Fields

The message body of management messages for cryptographic support (message type K), must contain the following fields:

4.3.5.2 Cryptographic Data Type Field

The CryptoDataType field defines the type of cryptographic key data to be exchanged, and must be a 2-byte UTF-8 encoded hexadecimal character from the following table with codes for each key type:

4.3.5.3 Cryptographic Data Field

The content of the CryptoData field is determined by the CryptoDataType field value as follows.

• When the data type is HDExtPubKey (code 01), the data field must contain the serialised extended public key used to derive the deterministic public keys (and addresses).

• When the data type is ECDHPubKey (code 0A), the data field must contain a compressed elliptic curve public key for a Diffie-Hellman key exchange.

• When the data type is InitVector (code 11 or 21), the data field must contain the 128-bit initialisation vector required to decrypt a message encrypted with the algorithm indicated with encryption indicator code 1 and 2 respectively.

The CryptoData field may be longer than 64 bytes if allowed by underlying blockchain. If the length of the CryptoData field is insufficient to provide the full data, an additional Cryptographic Support Messages may be sent with the rest of the key data using reference code 3.

Usage of the Cryptographic Support Message and the data types is detailed in Cryptographic Support Functions.

4.3.6 Management Messages: Test

4.3.6.1 Test Message Fields

The message body of test messages has an identical set of fields as signs & signals messages have, which allows to test sign and signals. A test message must contain the following fields:

4.3.5.2 Pseudo Message Code

The PseudoMessageCode field indicates which sign/signal message is tested. The contents of the field must be a 1-byte UTF-8 encoded alpha-numeric character value corresponding with one of the message types defined in Message functionality.

4.3.5.3 Other Test Message Fields

All other test message fields are identical in use as the equivalent fields sign/signal message, as described in Message Body, with the difference that the fields are shifted 1 byte / 8 bits.

The field names must be preceded by Test when used in a test message.

5 Protocol

5.1 Joining and Leaving the Whiteflag Network

5.1.1 Initial Authentication

It is not required to perform initial authentication and provide identity information to receive messages.

To send Whiteflag Messages on the network, the originator must have at least one blockchain account and address. An originator may use multiple accounts, and an account may use multiple addresses.

Each account must be identified by sending an A(0) initial authentication message, before sending any other message. Messages sent by an account before that account has sent a valid A(0) message, must be ignored.

If an account uses multiple addresses, the A(0) message must be sent using the address corresponding with public key from which all other addresses can be deterministically derived. For recipients to be able to derive those address, a K(3)2 message referencing the A(0) message must be sent, containing the chain code for child key derivation.

5.1.2 Validating Authentication Information

5.1.2.1 Method 1: URL Validation

The URL contained in the VerificationData field an A1 message must point to web resource. This allows the blockchain account to be linked to a web site, social media account, or any other web resource that identifies the originator. Consequently, the identification is as strong as the web resource used.

The URL should use the https: scheme to be able to ensure the validity of the resource.

At the URL, a flattened JSON Web Signature JSON serialization (JWS-JS) formatted object i.a.w. RFC 7515 - JSON Web Signature (JWS) must be found. This object contains a JSON object with authentication information together with only one digital signature.

The digital signature is used for authentication, non-reputation and data integrity; in other words: it ensures that only the owner of the web resource controls the blockchain account used to send the A message. The digital signature must be created using the key pair of the associated blockchain account, i.e. the account from which the A1 message has been sent.

Multiple JWS-JS objects may be returned from the same URL. The object(s) must either be returned directly or be embedded within HTML as follows:

    <script type="application/json" data-wf-auth-message="...">
        {
            "payload": "...",
            "protected": "...",
            "signature": "..."
        }
    </script>

The data-wf-auth-message html tag must be added if embedded in html. The tag should contain the transaction hash of the corresponding A1 message. This allows for easier lookup and parsing. The tag may be empty if the transaction hash is unknown at the time of publication, because the signature may have been created before the A1 transaction is send or processed on the blockchain.

The non-serialised payload must be a JSON object itself and must at least have the following properties: the originator’s blockchain address, the originator’s name, and the same URL as in the A message, as follows:

    "protected": {
        "addr": "...",
        "orgname": "...",
        "url": "...",
        "extpubkey": "..."
    }

in which:

• addr is the same blockchain address used to send the corresponding A1 message and of which the corresponding private key is used to create the signature;

• orgname is the name of the originator, which can be chosen freely;

• url is exactly the same URL as in the VerificationData field the corresponding A1 message.

If the originator uses deterministic keys and addresses, the payload must also contain information to derive the public keys:

• extpubkey is the serialised extended parent public key from which the child public keys and addresses used by this originator can be derived.

The serialisation format of an extended public key is blockchain specific. Although supported, deterministic keys should normally not be used.

An example for usage of JWS for authentication is included in Annex C.

5.1.2.2 Method 2: Shared Token Validation

The option to use a secret token for authentication allows the issuer of the token to authenticate the originator’s blockchain account when the token is revealed in an A2 message. The secret token may be pre-shared or generated from a shared secret as follows.

1. The token may be a secret piece of either arbitrary data or some (encrypted) meaningful data provided to the originator.

2. The token may also be derived from an ECDH shared secret as described in Key and Token Derivation.

The secret token must not be used directly in a single A2(0) message. Instead, the token must be hashed using the SHA-512 hashing algorithm in order to loose any information that may reside in the token and to create a sufficiently long token that can be sent in two parts. This is to prevent misuse of the token in the time between the propagation of the A2(0) transaction and a secure number of confirmations. The second part of the token must be sent with an A2(3) message after any reasonable number of confirmations of the A2(0) transaction, and only if the first part of the token is not used in an A2(0) message from another originator with a higher number of confirmations.

The following pseudocode reflects the procedure:

    publicToken := SHA512(secretToken)
    A2(0).VerificationData := publicToken[0..255]
    A2(3).VerificationData := publicToken[255..511]

    send(A2(0))
    A2(3).ReferencedMessage := A2(0).transactionHash
    if (A2(0).confirmations == n AND NOT(A2(0) == A2(0)X)) then:
        send(A2(3))

An originator may use multiple A2(0) < A2(3) sequences with tokens from different issuers or ECDH counterparts.

The issuer or ECDH counterparts may send A2(6) or A2(7) messages to confirm or acknowledge the claim, but also may choose not to do so to prevent others to record metadata on communications between parties.

5.1.3 Additional Authentication Information

Multiple tokens, URL verifications, or combinations thereof, may be sent for stronger authentication by sending multiple A(0) messages.

The authentication information in an A(0) or A(2) message may be updated with an A(2) message.

An A(3) message must be used when providing longer URLs or tokens than a single message A(0) or A(2) message can contain in its VerificationData field.

5.1.4 Leaving the Network

An account may leave the network with an A(4) message referencing the A(0) or latest A(2) message, whichever was sent last. Any message sent by an account after that account has sent an A(4) message must be ignored.

5.2 Cryptographic Support Functions

5.2.1 Hierarchical Deterministic Accounts and Addresses

It may not be assumed that every recipient is able to link deterministically derived addresses to the master public key of the account in order to authenticate the originator. Therefore, deterministic keys and addresses should normally not be used.

5.2.2 Key Agreement

The protocol supports cryptographic key exchange using Elliptic Curve Diffie-Hellman (ECDH), which is an Elliptic Curve variant of the standard Diffie-Hellman algorithm. This well known algorithm allows two parties, that do not have any prior knowledge of each other, to agree on a shared secret using an open communication channel. This shared secret may then be used, for example, to derive a secret key for the encryption of messages.

The OpenSSL implementation of ECDH is the reference implementation for for Elliptic Curve Diffie-Hellman key agreement with the Whiteflag Protocol. The elliptic curve parameters that must be used for Whiteflag are defined by the brainpoolP256r1 curve as specified in RFC 5639.

Any participant may generate a 264-bit compressed public ECDH key and publish the key on the Whiteflag network using a K(0)0A message. This allows any two participants who have both published their public key to generate the shared secret using their own private key and the other’s public key.

The shared secret may be used as a basis for encryption and authentication, whether or not defined within the scope of this standard, but it should never be used directly as an encryption key.

If one of the participants publishes an updated K(2)0A message, the existing shared secrets with other participants expire and new shared secrets must be generated for and by each other participant.

5.2.3 Key and Token Derivation

Encryption and decryption keys, as well as authentication tokens, may be derived from the generated ECDH shared secret as described above in Key Agreement. The HKDF function defined in RFC 5869 is used for key and token derivation. To derive the key of the required length, perform the following steps:

• take the SHA-256 hash from the ECDH shared secret;

• perform an HKDF function to generate the required AES key length, using the first 96 bits of the hashed shared secret as the “salt”, the second 160 bits as the “input key material” (IKM), and SHA-256 as the digest algorithm.

In addition to the parameters described above, the HKDF function takes two parameters depending on the encryption method or token type: the key/token length and a usage specific “info” string:

• for authentication method 2, the key length (token length) must be 64 bytes (512 bits) and the info string must be wf-auth-02;

• for encryption method 1 (aes-128-ctr) the key length must be 16 bytes (128 bits) and the info string must be wf-enc-01;

• for encryption method 2 (aes-256-ctr), the key length must be 32 bytes (256 bits) and the info string must be wf-enc-02.

This results in the following pseudocode for deriving authentication tokens:

    hashedSecret := SHA256(sharedSecret)
    salt := hashedSecret[0...96]
    ikm := hasedSecret[96...255]
    tokenlength := 64
    info := "wf-auth-02"
    secretToken := HKDF(ikm, salt, info, tokenlength, digest="sha256")

The pseudocode for deriving encryption/decryption keys is:

    hashedSecret := SHA256(sharedSecret)
    salt := hashedSecret[0...96]
    ikm := hasedSecret[96..255]
    if (EncryptionIndicator == 1) then:
        keylength := 16
        info := "wf-enc-01"
    if (EncryptionIndicator == 2) then:
        keylength := 32
        info := "wf-enc-02"
    key := HKDF(ikm, salt, info, keylength, digest="sha256")

5.2.4 Message Encryption

Two encryption methods are currently defined by Whiteflag: the Advanced Encryption Standard (AES) in counter mode (CTR) with either a 128-bit or a 256-bit key as described below.

AES is a symmetric cipher that requires the same key for encryption and decryption. This key may be pre-shared, deterministically derived with some pre-shared secret, or may be generated an ECDH shared secret as described in Key and Token Derivation.

5.2.4.1. Encryption Methods 1 and 2

Encryption of a Whiteflag message is performed with the following steps:

• generate a new random 128-bit initialisation vector;

• encrypt the compressed binary encoded message starting at bit 32 (the 33th bit) up to and including the last bit, using aes-128-ctr or aes-256-ctr with the appropriate key and the just generated initialisation vector.

Encryption steps in pseudocode:

    iv := generateRandomBits(128)
    encryptedMessagePart := aes(encodedMessage[32...n], key, iv, mode="ctr")
    encryptedMessage := encodedMessage[0...31] + encryptedMessagePart

The OpenSSL implementation of AES is the reference implementation for the usage of AES to encrypt and decrypt Whiteflag messages.

AES in counter mode requires a different initialisation vector for each message encryption, especially when reusing the same key. Therefore, a new random initialisation vector must be created for each message to be encrypted.

The encrypted message, with the correct encryption indicator set and the plaintext from the 5th byte onwards replaced with the ciphertext, must be sent as any other Whiteflag message.

The encrypted message must immediately be followed and referenced by a K(3)11 or a K(3)21 message containing the initialisation vector. Without the initialisation vector the message cannot be decrypted by the recipient. The K message must not be encrypted itself, and the duress indicator must be 0, regardless of the duress indicator value of the referenced encrypted message.

5.3 Sending stand-alone Signs and Signals

To send a stand-alone message, Reference Code 0 must be used.

However, nothing prevents other senders to reference the message at any later point in time, thus creating a message sequence from a previously stand-alone message.

A message is sent by embedding it in a blockchain transaction. The way this is done is blockchain specific. Annex A contains some information about message embedding for a limited number of blockchains.

5.4 Referencing

5.4.1 Reference options

5.4.1.1 Allowed Referencing between Message Types

The table below shows which references types (as defined in Reference Indicator Field) may be used between the different message types, and which reference types are not allowed.

X: prohibited T: a test message may make any reference for testing purposes

5.4.1.2 Allowed Referencing between Reference Types

The table below shows which reference types (as defined in Reference Indicator Field) may be used to refer to an earlier message with a certain reference code to create a meaningful message sequence.

Same: reference code allowed by the same originator of the referenced message Other: reference code allowed by an other originator than of the referenced message Both: reference code is allowed by both the same or an other originator than of the referenced message X: prohibited

A message with Reference Code 0 (an original message) may not reference any message.

A message with Reference Code 1 (a recall message) may reference a message with any reference code of the same originator, meaning that a message with any reference code can be recalled.

A message with Reference Code 2 (an update message) may only reference a message with reference code 0, 3, or 5 meaning that only original, additional, and referring messages may be updated and only by the same originator.

A message with Reference Code 3 (an additional information message) may only reference a message with reference code 0, 2, or 5, for the same originator to provide additional information to original, updating and referring messages.

Reference Code 3 may be only used once to refer to the original message of the same message type. For example: R(0) < R(3) and [R(0)] < K11(3) << [R(3)] < K11(3) are allowed, but R(0) < R(3) << R(3) is not. There is one exception: Reference Code 3 may be used to reference the same message type of types P, D, Q, and M more than once, when creating composite areas (see Composite Areas and Structures). In that case, the additional information must reference the initially referenced message and may not reference another message with additional information, e.g. D(0) < D(3) << D(3) <<< D(3)

A message with Reference Code 4 (a discontinue message) may only reference a message with reference code 0, 5, 6, 8, or 9 of the same originator, because an only originator may only discontinue an original, related, confirmation, comply or reject message. Discontinuing a message also implies that any later updates to that message are discontinued.

A message with Reference Code 5 (a referring message) may only reference a message with Reference Code 0 or 5, i.e. to refer to an original or another referencing message.

A message with Reference Code 6 (a confirmation message) may only reference a message with Reference Code 0, 2, 3, 4, or 5, i.e. confirming an original, updated, additional information, expiration, or related message.

A message with Reference Code 7 (an acknowledgement message) may only reference may only reference a message with reference code 0, 2, 5, 8 or 9, to acknowledge an original, updated, related, comply or reject message.

A message with Reference Code 8 (a comply message) may only reference a message with Reference Code 0, 2, or 5, i.e. to indicate the originator will act upon or in accordance with an original, updated, or a related message from another originator.

A message with Reference Code 9 (a reject message) may only reference a message with Reference Code 0, 2, or 5, i.e. to indicate that the originator rejects, denies or does not agree with the referred original, updated, or a related message from another originator.

5.4.2 Message Sequences

When referencing messages are referenced themselves, message sequences may be created. The paragraphs below describe which message sequences, as allowed by the reference options described in Reference Indicator Field, provide meaningful information.

5.4.2.1 Authentication

An A message may only reference another A message, in order to:

• recall the A(0) message with Reference Code 1;

• update the A(0) message with Reference Code 2, e.g. to provide new authentication information;

• provide additional information with Reference Code 3, when the authentication information is too long to provide in the VerificationData field of a single message;

• to discontinue the original A(0) with an A(4) message, meaning the originator leaves the network;

• to confirm the claimed identity of another originator by referencing its A(0) message with an A(6) message.

For example, an initial authentication of originator X using an URL of 30 bytes, which is confirmed by another party Y, later updated with an URL of the same length, and finally the account is closed, will result in the following message sequence:

A01(0)X < A01(3)X << A01(6)Y <<< A01(2)X < A01(3)X <<<<< A01(4)X

5.4.2.2 Updating Signs and Signals

Conflicts and disasters are dynamic and events end or change. Therefore, the protocol allows to update signs and signals using message sequences with Reference Codes 2, 3 and 4.

The following example are illustrative for updating signs and signals and should be interpreted similarly when updating other signs and signals:

5.4.2.3 Relating Signs and Signals

Events are often related. For example, a dangerous situation such as a wildfire may cause multiple buildings to be destroyed and multiple emergencies. The protocol allows to relate the different signs and signals for these events to create a better understanding of a situation.

A typical sequence of message will be a danger/disaster sign, followed by one or more status and emergency signals using Reference Code 5, which may be used to reference messages from any other account.

The following examples are illustrative for relating signs and signals and should be interpreted similarly when relating other signs and signals:

5.4.2.4 Confirming Signs and Signals

Conflict and disaster zones are chaotic and it is often difficult to assess a situation based on a single source of information. To improve the reliability of information, the protocol allows another originator to confirm of signs and signals posted on the network using Reference Code 6.

The following examples are illustrative for confirming signs and signals and should be interpreted similarly when confirming other signs and signals:

5.4.2.5 Composite Areas and Structures

A composite area is a single area specified by multiple messages. A composite structure is a single structure specified by multiple messages. Composite areas and structures may be used, for example, when an area/structure is larger than the ObjectSize fields allows, or to create areas/structures with shapes other than the ObjectType field allows.

To report a new composite area or structure, the first message must have its Reference Indicator set to 0 (original message), and any following message in the sequence must reference the original message using Reference Indicator 3. The referencing messages must have the same Subject Code as the original message.

For example, a single mine field comprised of three area parts is reported on the network with the following message sequence:

D21(0) < D21(3) << D21(3)

Composite areas may only be created using messages with Object Code 20-29. Composite structures may only be created using messages with Object Code 30-39.

To reference a composite area or structure as a whole (e.g. to dsicontinue it using Reference Code 4 or to confirm it using Reference Code 6), the referencing message must reference the original message.

An update message (Reference Code 2) may reference individual messages of the sequence, and thus updating each part of the composite area/structure separately. A recall message (Reference Code 1) may either reference the original message, or individual messages of the sequence.

5.5 Testing

Test messages must be disregarded for any other purposes than testing. Test messages should only be used on testing networks of blockchains.

A test message may reference any other message for testing purposes.

Annex A. Blockchain specific details

* including forked blockchains such as Bitcoin Cash and Litecoin

Annex B. JSON Schema of Whiteflag Messages

(contained in separate file)

Annex C. Example JSON Authentication Objects

The JSON representation of an A1 message sent using the example static Bitcoin address 1C8KSK68SJjfDSBx9BpSx3qB3bePf23r77 may be as follows:

{
    "MetaHeader": {
        "example": true
    },
    "MessageHeader": {
        "Prefix": "WF",
        "Version": "1",
        "EncryptionIndicator": "0",
        "DuressIndicator": false,
        "MessageCode": "A",
        "ReferenceIndicator": "0",
        "ReferencedMessage": "0000000000000000000000000000000000000000000000000000000000000000"
    },
    "MessageBody": {
        "VerificationMethod": "1",
        "VerificationData": "https://organisation.int/whiteflag"
    }
}

The related JSON formatted object with the authentication information to be signed and published at the provided URL https://organisation.int/whiteflag would be:

{
    "addr": "1C8KSK68SJjfDSBx9BpSx3qB3bePf23r77",
    "orgname": "Organisation Name",
    "url": "https://organisation.int/whiteflag"
}

This object is then used as the payload to create a JSON Web Signature (JWS) object that includes a digital signature created with the private key of the Bitcoin address. The compact serialization specified by the JWS standard would normally result in the following token:

eyJhbGciOiJFUzI1NiJ9.eeyJhZGRyIjoiMUM4S1NLNjhTSmpmRFNCeDlCcFN4M3FCM2JlUGYyM3I3N
yIsIm9yZ25hbWUiOiJPcmdhbmlzYXRpb24gTmFtZSIsInVybCI6Imh0dHBzOi8vb3JnYW5pc2F0aW9u
LmludC93aGl0ZWZsYWcifQo.XWBRA1TrCxs8tpep1lLPcmpp9JlO_A0TJB5ULOROvadje3SgAsfkFEj
E2DoHGpWJ_zNGlEPBtdUQo9MEypIp2Q

However, for practical purposes (such as easy embedding in HTML) the object published at the provided URL must be a flattened JWS JSON Serialization object:

{
    "protected": "eyJhbGciOiJFUzI1NiJ9",
    "payload": "eeyJhZGRyIjoiMUM4S1NLNjhTSmpmRFNCeDlCcFN4M3FCM2JlUGYyM3I3NyIsIm
                9yZ25hbWUiOiJPcmdhbmlzYXRpb24gTmFtZSIsInVybCI6Imh0dHBzOi8vb3JnY
                W5pc2F0aW9uLmludC93aGl0ZWZsYWcifQo",
    "signature": "XWBRA1TrCxs8tpep1lLPcmpp9JlO_A0TJB5ULOROvadje3SgAsfkFEjE2DoHG
                  pWJ_zNGlEPBtdUQo9MEypIp2Q"
}

The equivalent a fully unserialized JSON object representation is provided here as human readable example:

{
    "protected": {
        "alg": "ES256"
    },
    "payload": {
        "addr": "1C8KSK68SJjfDSBx9BpSx3qB3bePf23r77",
        "orgname": "Organisation Name",
        "url": "https://organisation.int/whiteflag"
    },
    "signature": "XWBRA1TrCxs8tpep1lLPcmpp9JlO_A0TJB5ULOROvadje3SgAsfkFEjE2DoHG
                  pWJ_zNGlEPBtdUQo9MEypIp2Q"
}

Note that the used algorithm (ES256, i.e. ECDSA using P-256 and SHA-256, in line with the underlying blockchain for the example, i.e. Bitcoin) is included in the protected header.

Annex D. Definitions

Below is an overview of terms as used in this standard within the context of Whiteflag.

Annex E. Signs & Signals Equivalents

(contained in separate repository)

Annex F. Example Use Cases

Use case 1: NGO Area Access to Provide Aid

A humanitarian convoy is carrying emergency assistance for affected populations in a conflict zone. First of all, the authenticity of the blockchain account of the aid organisation is validated with an A2(0) message and can be reinforced on a regular basis with A2(2) updates.

In order to safely reach their destination, the aid organisation needs to request area access in advance to all parties to the conflict. These requests are made using Q messages, with which the following information is provided: trajectory, dates, vehicles and personnel. The aid organisation is able to send these request encrypted to each party individually by generating a unique encryption key for that party using the K0A messages on the blockchain.

Parties can indicate the receipt and compliance with the request by using reference codes 7 and 8. Last but not least, a party may withdraw its compliance with the request at any time by sending a Q(9) deny message. This would result in the following sequence:

Q20(0)A < Q20(3)A ... << Q(7) <<< Q(8) ... <<<< Q(9)

While on the road, the convoy is able to quickly inform other humanitarian actors of potential changes in the environment as well as receive as much as possible live information while driving, by using protection and danger signs, e.g. the P11 protective sign, D13 bomb attack, D21 unexploded ordnance, DA5 bomb attacks, D51 uncontrolled uprising, etc.

Once on location, a protective sign is sent. In order to achieve meaningful humanitarian action, the NGO also communicates the type of assistance provided using M messages to avoid duplication and inefficiency of humanitarian aid:

P11(5) < M(5)

Use case 2: Protected Sites and Critical Infrastructures

Since messages are persistent on a blockchain, an organisation can utilize the Whiteflag Protocol to create a public digital register of sites that are protected under international law using P messages. In addition, I messages are used for notifications about infrastructures that are not necessarily protected under international law, but are important for NGO operations or for affected populations and refugees: e.g. water treatment facilities, power plants, food distribution location, shelter, NGO warehouses, using I messages.

This information might be shared to prevent unintended air attacks, but also to share information between NGOs and the UN. For example, an NGO maintains a continuously updated overview of critical infrastructures and a register of hospitals on the Whiteflag network, including status updates. It is an operational decision to disclose or encrypt the information to prevent abuse.

Currently, this type of information is not always confirmed or denied afterwards. Using Whiteflag, other parties can confirm the information by using reference code 6, e.g.:

I(0) < I(6) ... P31(0) < P31(6)

A message sequence where a hospital is identified, a party indicates it will comply with its protected status, and the status of the hospital is periodically updated, will look like:

P31(0) < P31(8) << S(5) ... < S(2)

Another example is a local cultural institute C that can create a public digital register of monuments in its city or village by posting a protective sign at each monuments location, using P52 messages (protective sign for a cultural property).

When a protected site or critical infrastructure ever comes under attack, this can be broadcasted immediately by anyone using the Whiteflag Protocol, sending for example a D11 message (structure under ground attack), resulting in the following message sequence:

P52(0)C < D11(5)

Were the attack undertaken by a party that intends to comply with international law (for which reason such a party might very well actively use the Whiteflag Protocol), that party would be immediately informed of their mistake allowing them to cease fire before any more damage is done.

If the attack is performed by a non-compliant armed group, the Whiteflag Protocol ensures that the attack is recorded and known to the international community, allowing for example peacekeeping forces to react and/or providing evidence for the war crime.

Use case 3: Peacekeeping Forces Confirm a Mine Field Reported by Locals

The Whiteflag Protocol allows to digitally mark dangerous zones, such as minefields or areas where unexploded ammunition is present. Suppose local civilians are aware of an area where mines are present. A local aid worker A might report such an area by sending one or more D21 messages using a special app on her smartphone. The information about the dangerous area is available immediately to civilians, NGOs, journalists etc., even though the information about the mine field might not yet considered accurate or true by everybody.

Based on the original message, a UN peacekeeping unit or UNMAS (U) plan to investigate the area. Once they can confirm it is a minefield, a higher-level UN headquarters sends a confirmation message using a UN information system with a Whiteflag interface through a well-known and validated UN blockchain account.

A link to an UNMAS website with additional information (mine types, quantity, level of danger, stay clear area, current de-mining status) is provided using an R message, which can be resent when the is updated.

This scenario resulted in the following message sequence:

D21(0)A < D21(6)U <<< R(5)U ... < R(2)U

It would be very easy for anyone to develop a web application to actively monitor all these sorts of messages and project this information on a map, creating broad awareness of the danger among aid workers and local populations.

Use case 4: Proof of Life by a Journalist

A journalist working in a combat zone wants to let his news agency know where he is on a regular basis. To do this, the journalist makes his blockchain account known by sending an A2 message containing a token that was provided to him by his news agency. He can now be positively identified on the network by his news agency, while his identity is not made public.

From now on, the journalist can send an S11 (proof-of-life status message) on a regular basis, either with or without his location. For extra security, it is possible to encrypt the message to ensure only recipients know where he is.

Use case 5: Negotiate a Cease Fire between Fighting Parties

Warring parties can use Whiteflag to negotiate a cease fire, e.g. to be able to provide medical care in a specific area for a certain amount of time. In the following example sequence, party A requests a cease fire using a Q message with additional information included in an F message; parties B and C agree with the request by responding with reference code 8:

Q(0)A < F(5)A << Q(8)B <<< Q(8)C

Note that Whiteflag is limited to fixed messages and in itself not suitable to conduct detailed negotiations. However, even though other communication channels are used to come to a cease fire, Whiteflag allows to undeniably record the request and any outcomes.

Use case 6: Armed Group under Air Attack wants to Surrender

Imagine an armed group A is under a heavy air attack, and the remaining combatants want to surrender. However, it is very unlikely that they are in radio contact with the pilots, and the pilots might not see a physical white flag.

The Whiteflag Protocol can be used to send a message to the attacking party, without knowing any contact details. An A2(0) message is sent, or has been sent before, referring to some sort of social media channel that is known to be used by the armed group. The blockchain account is now linked to this group, and a P03(0) surrender message is sent.

If a headquarters or command centre of the attacking party M is listening on the Whiteflag Network for situational awareness, they will be instantaneously informed of the digital white flag on the location under attack. Of course, the trustworthiness of the message needs to be evaluated based on earlier communications from the same account, other intelligence, confirmation by other parties on the network, the actual behaviour of the armed group at the location, etc.

Either way, the information can be relayed over a military data link to the pilots in the aircraft, who might then be able to visually confirm a white flag. Once that is the case, the attacking party M can send both a confirmation and an acknowledgement. This scenario resulted in the following message sequence:

A2(0)A < P03(0)A < P03(6)M << P03(7)M