Skip to content

Latest commit

 

History

History
49 lines (35 loc) · 5.36 KB

security.md

File metadata and controls

49 lines (35 loc) · 5.36 KB

Security

Let us begin by establishing that the Eiffel protocol by itself can be considered neither secure nor insecure, any more than English is secure or French is insecure. Security is not a property of the language or the protocol as such, but of how it is communicated and managed. That being said, security is a highly relevant concern, and where feasible Eiffel supports it. It is important to understand that security is a broad concept, however, and that feasibility varies depending on the type of security in question. In literature, the three key concepts of security (sometimes referred to as the CIA triad) are confidentiality, integrity and availability. We will discuss each of these in turn.

Confidentiality

In the words of ISO27000, confidentiality means that "information is not made available or disclosed to unauthorized individuals, entities, or processes". This can be achieved through multiple (and often complementary) means, such as encryption and access control. The Eiffel protocol itself cannot support confidentiality; instead it is a property of the systems used to transport, process and store the Eiffel events. In other words, if the confidentiality of information communicated as Eiffel events is a concern for you, then you are recommended to take appropriate action to ensure the confidentiality of your data, both at rest and in transit, e.g. through encryption.

Integrity

In information security, integrity refers to the accuracy and completeness of data. In other words, safeguarding integrity requires protection against both malicious and unintentional tampering with or corruption of data in an unauthorized or undetected manner. This cannot be solved by a communication protocol, as it relies on adequate infrastructure and processes for managing the data, but it can be supported. Eiffel supports two aspects of data integrity; integrity of event payloads and integrity of referenced items.

Integrity of event payloads

The integrity of the contents of an Eiffel event, i.e. its payload, can be protected via a digital signature. A digital signature is a combination of hashing technology and encryption. Hash functions are commonly used to ensure data integrity and are familiar to most software professionals. By using checksums or hash values (particularly hash values, or digests, produced by cryptographic hash functions such as the SHA series), any piece of data of arbitrary length is computed into a fixed length digest, with any alteration of the input data resulting in a different digest. Consequently, as long as the digest of the received data matches the digest of the data sent, its integrity can be verified. Unfortunately, the digest must be securely communicated: any malicious attacker able to not only manipulate the data but also the digest can make a corrupted message appear authentic. This is why digital signing also employs encryption.

The Eiffel protocol's support is influenced by JSON Web Signatures (JWS), with slight modifications to allow inclusion of the signature within the event message itself, rather than as part of a header. This serves to keep every Eiffel event self-contained, with information integrity protection optional for the producer to include and optional for the consumer to consider. Note that this optionality does not in any way lessen the strength of the security provided: it is always up to the recipient of an unprotected Eiffel event to decide whether to trust it or not. In this sense, Eiffel support of data integrity is very similar to that employed by other document formats, such as the Portable Document Format.

Apart from digital signing, the Eiffel protocol also supports author identification using Distinguished Names and event sequence integrity protection. Please see the documentation of each event type for further information and detailed instructions on correct usage.

Integrity of referenced items

Some Eiffel events reference external data whose integrity is important to track, e.g. the files that make up an artifact. In this case a cryptographic digest of the data is stored in the Eiffel event, allowing event consumers to verify that the data hasn't been modified by either an honest mistake, corruption, or malicious intent. The use of such a digest may be combined with a digital signature of the event to secure the integrity of the digest.

Availability

Availability of information communicated over the Eiffel protocol is a property of the communication channels and storage solutions used. In other words, similarly to confidentiality, it is an infrastructural concern and external to the protocol itself.