Commit efc412df authored by Peter Waher's avatar Peter Waher

End-to-End encryption

parent 0eb203c9
......@@ -15,7 +15,7 @@ Motivation and design goal
The method of end-to-end encryption (E2E) described here, is designed with the following goals in mind:
* Peers should be able to negotiate which algorithms to use.
* Peers should be able to choose which algorithms to use.
* Hybrid algorithms should be supported, where an asymmetric cipher with a public/private key pair is used to negotiate a symmetric key for a symmetric
cipher, that is used to encrypt/decypt the payload of the stanza. The symmetric key is unique for each stanza.
......@@ -33,35 +33,35 @@ public/private key pair are affected.
Publishing E2E Information
-------------------------------
When a device starts, it should generate new public/private keys. Everytime it gets connected it should publish the public keys using `persence`, so that
everyone with a presence subscription is aware of the currernt public key. Everytime a new public/private key is generated, it should also publish the public
key in a new `presence`. Apart from the most receive public/private key pair, the previous pair should also be kept in memory. Since there might be a delay
When a device starts, it should generate new public/private keys. Everytime it gets connected it should publish the public key(s) using `presence`, so that
everyone with a presence subscription is aware of the currernt public key(s). Everytime new public/private keys are generated, the public keys should also be
published in a new `presence`. Apart from the most recent public/private key pair, the previous pair should also be kept in memory. Since there might be a delay
in propagating the new key, it allows the recipient to receive and decrypt stanzas that have been encrypted using the previous key.
Hybrid Ciphers
--------------------
Cyphers used in E2E have two components: An assymetric cipher using a public key for encryption and signature validation, and a private key for
decryption and signature generation. This cipher is used to negotiate one-time symmetric keys for a symmetric cipher used to encrypt and decrypt the
actual payload. Once the symmetric key has been used, it is discarded. The assymetric keys are regenerated as often as required by the sensitivity of
decryption and signature generation. This cipher is used to negotiate symmetric keys for an underlying symmetric cipher used to encrypt and decrypt the
actual payload. Once the symmetric key has been used, it can be discarded. Assymetric keys are regenerated as often as required by the sensitivity of
the data being communicated.
Presence instead of handshake
----------------------------------
To avoid having to negotiate keys when setting up E2E communication, public keys are published using `presence`. This allows anyone to send a message to
the entity, without first having to do a handshake. The sender can make the decision without handshake, and the receiver will be able to decrypt it. The
number of E2E stanzas transmitted and received is the same as the number of unencrypted stanzas, plus the number of presence stanzas transmitted. While this
typically reduces the number of messages required to estblish E2E communication between peers, it is not designed for the generation of new public keys
for every single stanza. Instead, public/private keys are generated on a timely fashion, depending on context, or after concluding a series of stanzas
(a communication session), so that anyone starting a new E2E session with the entity does so using new keys. Public keys should still be short-lived,
To avoid having to negotiate keys when setting up E2E communication, public keys are published using `presence`. This allows anyone to send an end-to-end
encrypted message to the entity, without first having to do a handshake. The sender can make the decision without a handshake, and the receiver will be able
to decrypt it. The number of E2E stanzas transmitted and received is the same as the number of unencrypted stanzas, plus the number of presence stanzas
transmitted. While this typically reduces the number of messages required to estblish E2E communication between peers, it is not designed for the generation
of new public keys for every single stanza. Instead, public/private keys are generated on a timely fashion, depending on context, or after concluding a series
of stanzas (a communication session), so that anyone starting a new E2E session with the entity does so using new keys. Public keys should still be short-lived,
as to not risk all historic messages to be broken, in case a public/private key pair is broken (forward secrecy).
RSA/AES
------------
The `rsaAes` algorithm combines RSA public/private keys with AES-256 symmetric cipher (using Cipher Block Chaining (CBC) and PKCS#7 padding) to establish
E2E between two entities. The RSA keys are used to encrypt the AES keys and initialization vectos, as well as sign the payload by the sender (with SHA-256
E2E between two entities. The RSA keys are used to encrypt the AES keys and initialization vectos, as well as to sign the payload by the sender (with SHA-256
and PKCS#1 v1.5 padding).
When E2E encrypting a `message` stanza, it is encrypted in its entirety, and then placed in an `aes` element. This is then sent in a **normal**,
......@@ -74,6 +74,10 @@ When E2E encrypting an `iq` stanza, only the contents of the stanza is encrypted
On both cases, the signatures are calculated on the unencrypted part of the payload that is to be encrypted. Encoding of XML text to bytes is always done
using UTF-8 encoding.
**Note**: If the initiation vector (`ivRsa`) is not provided, the Initiation Vector is the first 16 bytes of the SHA-256 hash of the UTF-8 encoded `id`
attribute value of the corresponding stanza (i.e. parent element), which must be provided, and unique for the current key, concatenated with the `type`
attribute value of the same element, concatenated with the `to` attribute of the same element.
Example, when publishing public keys using `presence`:
```
......@@ -105,3 +109,4 @@ support Elliptic Curve Cryptography (ECC). ECC is able to maintain the same secu
ECC p521/AES
-----------------
......@@ -5,7 +5,7 @@
xmlns='urn:ieee:iot:e2e:1.0'
elementFormDefault='qualified'>
<!--
<!--
Copyright 2017-2018 The Institute of Electrical and Electronics Engineers,
Incorporated (IEEE).
......@@ -68,11 +68,92 @@ purposes.
</xs:annotation>
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="p521Aes"/>
<xs:element ref="p384Aes"/>
<xs:element ref="p256Aes"/>
<xs:element ref="p224Aes"/>
<xs:element ref="p192Aes"/>
<xs:element ref="rsaAes"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:complexType name="ecAes" abstract="true">
<xs:annotation>
<xs:documentation>Base class for hybrid algorithms using Elliptic Curve ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:attribute name="x" type="xs:base64Binary" use="required">
<xs:annotation>
<xs:documentation>X-coordinate of public key. Most significant byte sent first.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="y" type="xs:base64Binary" use="required">
<xs:annotation>
<xs:documentation>Y-coordinate of public key. Most significant byte sent first.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:element name="p521Aes">
<xs:annotation>
<xs:documentation>End-to-End encryption using the NIST P-521 curve, ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ecAes">
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="p384Aes">
<xs:annotation>
<xs:documentation>End-to-End encryption using the NIST P-384 curve, ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ecAes">
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="p256Aes">
<xs:annotation>
<xs:documentation>End-to-End encryption using the NIST P-256 curve, ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ecAes">
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="p224Aes">
<xs:annotation>
<xs:documentation>End-to-End encryption using the NIST P-224 curve, ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ecAes">
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="p192Aes">
<xs:annotation>
<xs:documentation>End-to-End encryption using the NIST P-192 curve, ECDH key exchange to generate symmetric key for AES-256 encryption and ECDSA signatues.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ecAes">
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="rsaAes">
<xs:annotation>
<xs:documentation>End-to-End encryption using RSA Public Key cryptography to encrypt shared secrets, that are then used with AES-256 to encrypt the payload.</xs:documentation>
......@@ -100,23 +181,39 @@ purposes.
<xs:annotation>
<xs:documentation>AES-256 encryption of payload, using Cipher Block Chaining (CBC) and PKCS#7 padding.</xs:documentation>
<xs:documentation>Payload must not be accepted if the decryption fails or if the signature does not match the signature generated by the public key of the sender that the receiver has on record.</xs:documentation>
<xs:documentation>Initiation Vector (IV) is the first 16 bytes of the SHA-256 hash of the concatenation of the id, type and to attributes values of the stanza element.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="keyRsa" type="xs:base64Binary">
<xs:attribute name="keyRsa" type="xs:base64Binary" use="optional">
<xs:annotation>
<xs:documentation>Random AES key is encrypted using the public RSA key of the recipient.</xs:documentation>
<xs:documentation>Required attribute, if RSA/AES E2E encryption is used.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="ivRsa" type="xs:base64Binary">
<xs:attribute name="signRsa" type="xs:base64Binary" use="optional">
<xs:annotation>
<xs:documentation>Random Initialization vector is encrypted using the public RSA key of the recipient.</xs:documentation>
<xs:documentation>Payload signature using the public RSA key of the sender.</xs:documentation>
<xs:documentation>Required attribute, if RSA/AES E2E encryption is used.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="signRsa" type="xs:base64Binary">
<xs:attribute name="ec" type="EllipticCurve" use="optional">
<xs:annotation>
<xs:documentation>Payload signature using the public RSA key of the sender.</xs:documentation>
<xs:documentation>Name of Elliptic Curve used in ECDH key exchange to derive AES key used to encrypt the message, and ECDSA to sign message.</xs:documentation>
<xs:documentation>Required attribute, if EC/AES E2E encryption is used.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="ecdsa1" type="xs:base64Binary" use="optional">
<xs:annotation>
<xs:documentation>First integer in ECDSA signature of payload. Most significant byte sent first.</xs:documentation>
<xs:documentation>Required attribute, if EC/AES E2E encryption is used.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="ecdsa2" type="xs:base64Binary" use="optional">
<xs:annotation>
<xs:documentation>Second integer in ECDSA signature of payload. Most significant byte sent first.</xs:documentation>
<xs:documentation>Required attribute, if EC/AES E2E encryption is used.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
......@@ -124,4 +221,17 @@ purposes.
</xs:complexType>
</xs:element>
<xs:simpleType name="EllipticCurve">
<xs:annotation>
<xs:documentation>Recognized elliptic curve names.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="NIST P-192"/>
<xs:enumeration value="NIST P-224"/>
<xs:enumeration value="NIST P-256"/>
<xs:enumeration value="NIST P-384"/>
<xs:enumeration value="NIST P-521"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment