diff --git a/_docs_explore/22-security.md b/_docs_explore/22-security.md index fe451b7a6..9374a108b 100644 --- a/_docs_explore/22-security.md +++ b/_docs_explore/22-security.md @@ -52,7 +52,7 @@ Enmeshed uses the highest standards of encrypted communication. It is end-to-end For technical communication with contacts, the contact-specific signature keypair is used. Thus, every message of enmeshed contains multiple digital signatures of the same message, one signature per recipient (as the sender communicates with a different private key per contact). The digital signature enforces that only the sender can sign the payload and that nobody in between could tamper with the message itself, e.g. change the message payload. -A timestamp from the sender's device is included within the signed content. This reduces the risk of replay attacks (an encrypted message is sent again to the recipient without knowing the content) on the client side and might be used for legal purposes (sender's signing date). In addition to that, a unique message id for every message is generated by the Backbone and thus replay attacks are not possible without the control of the Backbone. +A timestamp from the sender's device is included within the signed content. This reduces the risk of replay attacks (an encrypted message is sent again to the recipient without knowing the content) on the client side and might be used for legal purposes (sender's signing date). It is explicitly enforced, that the addresses of all recipients of the mail are included in the signed content as well. This eliminates the risk of forward attacks, i.e. an attacker forwarding an encrypted mail to another person. @@ -60,16 +60,20 @@ The message payload is symmetrically encrypted with a randomly generated high en Thus, a message consists of multiple ciphers, one for the message content and one cipher for every recipient. In other words: Every recipient receives the same symmetric key (to decipher the message content) with a contact-specific key cipher which only the respective recipient can decrypt with a specific derived key. The same message with the same cipher of the message content can thus be decrypted by different recipients. -Once the signing and encryption processes are done, the sender submits the encrypted message to the Backbone. The Backbone creates a unique id for this message, in addition to a Backbone timestamp - which is in fact the timestamp on which every participant would agree on. +Once the signing and encryption processes are done, the sender submits the encrypted message to the Backbone. The Backbone creates a unique id for this message, with which replay attacks can be identified. It is also creating a timestamp for the creation date of the message. Such a timestamp from a trusted third party (in this case the Backbone) could act as the transmission timestamp on which the communication parties would usually agree on. The Backbone then notifies all recipients that a new message is available. Once a device of a recipient receives the notification, it fetches the message from the Backbone. The Backbone set the received timestamp for this recipient and the device. With it, the message counts as delivered. +# Trusted Timestamps + +So far, the Backbone is not using digitally signed timestamps by officially certified trusted timestamp authorities. It is using the timestamps of the cloud services, which are synchronized with public time servers. + # Law Enforcement Compliance It is possible to temporarily or permanently block access or delete identities, if illegal activities are brought to the attention of the Backbone's operator. For this the Backbone operator requires the help of at least one of the parties which received illegal content from a sender. -In addition, enmeshed supports law enforcement up to a certain degree. As like any other central provider, it is possible to block access or delete content if the Backbone operator gets the official task to comply (although the Backbone operator wouldn't know who the user is or which content it deletes). +In addition, enmeshed supports law enforcement up to a certain degree. As like any other central provider, it is possible to block access or delete content if the Backbone operator gets the official task to comply. For this, the Backbone operator would need detailed information about the identity or the payload from the law enforcement agencies. -Additionally, it is possible to point law enforcement organizations to other identities which have communicated with an unknown target identity in the past. If the actual real-world entity behind such an identity is known (e.g. a company) they might know who the target identity is and could further help law enforcement. +Additionally, it is possible to point law enforcement entities to other enmeshed identities which have communicated with an target identity in the past. If the actual real-world entity behind such an identity is known (e.g. a company) they might know who the target identity is and could further help law enforcement. diff --git a/_docs_explore/62-cryptography.md b/_docs_explore/62-cryptography.md index a2c771d0f..82faede82 100644 --- a/_docs_explore/62-cryptography.md +++ b/_docs_explore/62-cryptography.md @@ -5,19 +5,17 @@ permalink: /explore/cryptography # Backbone Layer Encryption -The communication with the Backbone is encrypted on the http transport layer. This is done by using the transport-layer-security (TLS) standard which is common throughout the Internet. This prevents third parties to access any data communication to and from the Backbone. +The communication with the Backbone is encrypted on the http transport layer. This is done by using the transport-layer-security (TLS) standard which is common throughout the Internet. This prevents third parties to access any data communication to and from the Backbone, like authentication tokens of devices, recipient addresses, timestamps. -Data at rest is encrypted on the respective systems. This is relevant for the underlying infrastructure services of the Backbone. The infrastructure provider, e.g. Microsoft Azure, is not able to access the data from the hard drives, as it is encrypted. +Stored data - so called "data at rest" - is encrypted on the respective systems, like databases. This is relevant for the underlying infrastructure services of the Backbone. The cloud infrastructure provider, is not able to access the data from the hard drives, as it is encrypted. # Transport Layer Encryption -The communication between identities via the Backbone is end-to-end encrypted. This is done by using our own cryptography library based on standard implementations of elliptic curve cryptograhic algorithms. - -This prevents even the operator of the Backbone to access the payload which is sent between identities. It is also reducing the threats of data leaks to a minimum, as only the metadata could be leaked. +The communication between identities via the Backbone is end-to-end encrypted. This means, that nobody between the digital identities (i.e. their devices) is able to access the data. This prevents even the operator of the Backbone to access the payload which is sent between identities. It is also reducing the threats of data leaks to a minimum, as only the metadata could be leaked. Such a metadata leak would be the same level of information leak as a public blockchain is doing all along its public network. We use modern cryptographic algorithms to our best knowledge. The cryptographic library we use is [libsodium](https://doc.libsodium.org/) and its JavaScript wrapper [libsodium.js](https://github.com/jedisct1/libsodium.js). Libsodium is a fork of NaCl which is primarily stripping out unnecessary or dangerours interfaces or algorithms. -Based on libsodium, we use elliptic curve cryptography with the Edwards Curve (Ed25519 or Curve25519) which is one of the most secure curves available - see [safecurves.cr.yp.to/](https://safecurves.cr.yp.to). +Based on libsodium, we use elliptic curve cryptography with the Edwards Curve (Ed25519 or Curve25519) which is one of the most secure elliptic curves available. It is used by the [Digital Signature Standard (DSS)](https://csrc.nist.gov/publications/detail/fips/186/5/final) and one of a few elliptic curves passing the tests on [safecurves.cr.yp.to/](https://safecurves.cr.yp.to). Additional references supporting the Edwards Curve are [The Provable Security of Ed25519: Theory and Practice](https://eprint.iacr.org/2020/823.pdf) and [Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/). Key derivations are used as often as possible, in addition to strong and unique initialization vectors. @@ -25,12 +23,20 @@ Key derivations are used as often as possible, in addition to strong and unique Symmetric Encryption: [XChaCha-Poly1305 (256 bit)](https://doc.libsodium.org/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction) -Digital Signatures: ECDSA Ed25519 (Elliptic Curve Digital Signature Algorithm with Curve25519) +Digital Signatures: ECDSA Ed25519 (Elliptic Curve Digital Signature Algorithm with Curve25519), 256bit + +Key Exchange: ECDH X25519 (Elliptic Curve Diffie Hellman with Curve25519), 256bit + +## Used Randomness + +To reach enough entropy for safe private and secret keys, key generation is based on randomness, which is very important for modern cryptography. Applications rely on cryptographic libraries for randomness which in turn use software-based randomness (like timestamps, calculation durations and seeds) and hardware-supported randomness (like sensor input, hardware ids or even dedicated ranomness modules). -Key Exchange: ECDH X25519 (Elliptic Curve Diffie Hellman with Curve25519) +Our randomness is based on the mentioned library [libsodium.js](https://github.com/jedisct1/libsodium.js) which is using the standard [WebCrypto APIs](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues). With the WebCrypto API, the browser's randomness generator is used. The browser uses either an own implementation of a secure Pseudo-Random-Generator, or - in modern browsers - the operating system's random generator, which is usually taking hardware into consideration. Our solution is thus using the same mechanisms the browser use for securing Transport Layer Security (TLS) communication over the world wide web. ## Identity Keys +Every Identity needs a set of keys used by the Identity in order to digitally sign information (Identity Signature Key) and enable cross-device synchronization (Synchronization Base Key). + ### Identity Signature Private Key Abbreviated: PrivId @@ -47,16 +53,14 @@ With the identity's public key, the identity's address is calculated. Usually, you receive another identity's signature public key while making the first contact (e.g. from the relationship template or the relationship request followed upon it). -### Synchronization Derived Secret Key - -The symmetric keys which are derived from the synchronization master key and are used to actually encrypt/decrypt the synchronization events. - -### Synchronization Master Secret Key +### Synchronization Base Secret Key -The symmetric master key which is used to derive the synchronization derived secret keys. The synchronization master secret key is randomly generated on creation for every identity. +The secret key which is used to derive the synchronization derived secret keys. The synchronization base secret key is randomly generated on creation for every identity. The symmetric keys which are derived from the synchronization base key and are used to actually encrypt/decrypt the synchronization events. ## Device Keys +One identity has one to many devices using the identity. In order to authenticate the devices between each other, a device creates an own signing key, which will never leave the device. + ## Device Signature Private Key Every device of an identity has its own private key which is also not shared to other devices. With this, it is possible to have multi-factor authentication capabilities across different devices of one identity. @@ -67,9 +71,19 @@ Additionally, the private signature keys can be used to sign data which is synch The device's public key which is stored in the Datawallet of an identity and thus is know to any other device of the identity. The public key can be used to verify data coming from other devices of an identity. -## File Encryption +## Symmetric Encryption + +Symmetric encryption is used throughout this solution in order to securely encrypt sensitive data. Prior to a communication to a different device or identity, a random secret key is generated and used to encrypt the payload. This secret key is then shared via a secure side-channel / out-of-band communication. This could be a message communicated over enmeshed, a QR-Code shown in a browser session or any other secure communication channel. The secret key is never transmitted unencrypted over the Backbone, as this would break up the end-to-end encryption. + +Examples where symmetric encryption is used: -As with tokens, prior to the upload, a random secret key is generated and used to encrypt the file payload. In addition to the file payload, metadata (like filename or mimetype) to the file is stored next to it. For this, another random secret key is generated for encrypting the metadata. To omit unnecessary payload while sharing files, the generated secret key for actual file payload is encrypted with its metadata, so that only the generated secret key for the metadata must be shared (in addition to the file id). +- Device-to-Device Synchronization +- Sharing Files +- Messages +- Relationship Templates +- Tokens + +For files only: In addition to the payload, metadata (like filename or mimetype) of the file needs to be separately encrypted. For this, another random secret key is generated for encrypting the metadata of the file. To omit unnecessary payload while sharing files, the generated secret key for actual file payload is stored within this metadata. Thus, only the generated secret key for the metadata must be shared (in addition to the file id). ## Relationship Keys @@ -85,7 +99,3 @@ With each relationship, there are relationship keys automatically generated. The - Relationship transmit derived secret key (SecOwn'): A derived symmetric key of the master, which is actually used for encryption. - Relationship transmit master secret key (SecOwn): The derived symmetric master key for transmitting communication to the relationship. The key is derived by the relationship peer exchange public key and the relationship own exchange private key. This key equals to the relationship receive master key of the peer. - -## Relationship Template Encryption - -## Token Encryption