|
Distributed Publish & Subscribe for IoT
|
DPS has two security mechanisms: end-to-end encryption and/or signing and link-layer encryption.
Publication and acknowledgement messages can be encrypted and/or signed end-to-end. Messages are encrypted and/or signed using COSE.
For privacy and to protect the network hop-by-hop links DPS uses link layer encryption where possible. IP multicast packets do not use link-layer encryption. Because DPS is fundamentally a multi-hop mesh protocol payloads are secured end-to-end.
As noted above publications and acknowledgement messages can be encrypted and/or signed using COSE. The protection in this case is end-to-end, the trust relationship is directly between the publishing node and the subscribing node, and intermediate nodes that simply route packets over the DPS mesh do not require a trust relationship with either the publishers or subscribers and do not hold keys. The publication or acknowledgement data payload is encrypted and/or signed, publications also carry the publication topic strings: these are included in the encrypted and/or signed payload. Message fields required for routing messages are integrity checked but obviously cannot be encrypted. The sending port number and TTL change on each hop so cannot be included in the end-to-end integrity check. The COSE format includes an optional KID (key-identifier) field. Encrypted DPS messages always have a KID which allows the different publications to use different encryption keys.
Subscriptions do not carry payload data and the bit vectors carried in the payloads get recomputed at each hop. Unlike publications and acknowledgements, subscriptions do not use COSE and rely solely on encryption at the link-layer.
Even when data is encrypted there are attack vectors based on traffic analysis. Traffic analysis is harder on a multi-hop mesh but because publications contain routing information that cannot be encrypted end-to-end. Specifically an attacker with access to a compromised node could use a dictionary attack to identify the topic strings in the publications and subscriptions flowing through that node. Where this is a concern the publishing and subscribing end-points can agree on a shared private encoding of topic strings, for example HMAC with a shared seed.
The following sections assume you are already familiar with the message encoding .
The protected section of a DPS message forms the protected attributes from the application as identified in COSE. The encrypted section of a DPS message is the plaintext provided to the content encryption algorithm and is replaced by a COSE object, one of COSE_Encrypt_Tagged, COSE_Encrypt0_Tagged, or COSE_Sign1_Tagged.
The implemented content encryption algorithm is A256GCM.
The encryption key is determined by the recipient algorithm. DPS supports the direct, A256KW, and ECDH-ES + A256KW recipient algorithms.
The use of the key wrap variants allows multiple recipients to be included in a message.
DPS supports the NIST P-384 (secp384r1) and NIST P-521 (secp521r1) curves.
Point compression is not supported. Both the x and y coordinates must be included in EC key representations such as the ephemeral sender key.
HKDF requires context information to be provided. This is represented in COSE as the COSE_KDF_Context.
The values of the identity, nonce, and other fields of the PartyUInfo and PartyVInfo structures in the COSE_KDF_Context are nil.
SuppPrivInfo is not included in the COSE_KDF_Context.
After encryption, the encrypted content is signed by the sender and the signature is included as a COSE counter signature. This allows intermediate DPS nodes to authenticate the sender of a message without decrypting the contents of the message.
DPS supports the ES384, and ES512 signature algorithms.
Alternatively, the plaintext content may also be signed by the sender in a COSE_Sign1_Tagged message. The protected section of a DPS message continues to form the protected attributes from the application as identified in COSE.
DPS supports the ES384, and ES512 signature algorithms.
An example encrypted publication message, using A256GCM for the content, ECDH-ES+A256KW for the key distribution, and ES512 for signing, will look like:
message = [
/ version / 1,
/ type / 1,
/ unprotected / {
/ port / 1: 42446,
/ ttl / 2: 0
},
/ protected (aad) / {
/ ttl / 2: 0,
/ pub-id / 3: h'C032D05B68D077BF53B4B1F356C05205',
/ seq-num / 4: 1,
/ ack-req / 5: false,
/ bloom-filter / 6: [1, 8192, h'00EC1780B702403900']
},
/ encrypted (COSE_Encrypt_Tagged) / 96(
[
/ protected / h'A101181E' / {
\ alg \ 1: 3 \ A256GCM \
} /,
/ unprotected / {
/ iv / 5: h'010000004032D05B68D077BF',
/ countersign / 7: [
/ protected / h'A1013823' /
\ alg \ 1: -36 \ ECDSA 512 \
} /,
/ unprotected / {
/ kid / 4: h'4450532054657374205075626C6973686572'
},
/ signature / h'017AA18776B87F9D39954F2DD8F8E74490B9B2EEA9092D73E6E35AB42485E4852B3C300A9DD39D1E19D4D47390AAE6DAA3FA80A5B71626B98E502E41EE019882FF250167096A3C25BD0BE4D56D8AA1D7ECB6089BDE0696B8F0D6C025AED2C448584E7DFA5DC95D8A5C28C2615FFD9F41AE7BEC541443CB3DAA04FC498A703F346572D31A'
]
},
/ ciphertext / h'C2DE85C0D3B991845A5B473D82CE176B4D2A16101FCC0BEE9E16783A',
/ recipients / [
[
/ protected / h'A101381E' / {
\ alg \ 1: -31 \ ECDH-ES+A256KW \
} /,
/ unprotected / {
/ ephemeral / -1: {
/ kty / 1: 2,
/ crv / -1: 3,
/ x / -2: h'00EFB0BDE7232A0D84C82A484104434D5866144F39D5C40F54985E13758A87E168C0004506C9D2B8D145FFD7AD90766A0BC5401EC0059339FC722FCA314019345571',
/ y / -3: h'00730F02A10FB0F669336487BE43C90B48BAB29E3B6637EABC352DA35B0B3576190D9A3A7A35832D3D75FA1EA24CC08418B7B04B27FF0C54EA0A23BD77EEAB077641'
},
/ kid / 4: h'44505320546573742053756273637269626572'
},
/ ciphertext / h'6C4832AE0347DD478D1D9E609FE37DB6BA21F5487CD9342256DEAB6813BEE62E88C24450FF55B4CF'
]
]
]
)
]
An example signed publication message, using ES512 for signing, will look like:
message = [
/ version / 1,
/ type / 1,
/ unprotected / {
/ port / 1: 44841,
/ ttl / 2: 0
},
/ protected (aad) / {
/ ttl / 2: 0,
/ pub-id / 3: h'CFE420F59A58D3319EB1B316D371BBA9',
/ seq-num / 4: 1,
/ ack-req / 5: false,
/ bloom-filter / 6: [1, 8192, h'004B00E9003700F3003C0340024000F880126C508020C044004B2201B409E807EC01440310005005EC0074079E009B801B34']
},
/ encrypted (COSE_Sign1_Tagged) / 18(
[
/ protected / h'A1013823' / {
\ alg \ 1: -36 \ ECDSA 512 \
} /,
/ unprotected / {
/ kid / 4: h'4450532054657374205075626C6973686572'
},
/ payload / h'A20B8165612F622F630C4D48656C6C6F20776F726C642100',
/ signature / h'01C619F247E6630EFB19C7FC911B5CC9A708B91E607437BDF3D2D1BD3EEF76355FED44D8CA5C5137F0AEF9959C01E52B7C92E461B04D84941E5FF954E70FAA26E0B4008EE950D93FA1EB59F5222086B61CCD39FB066880B2AF0DF455ABB8D7320E0E91F94AD529E3AAD9BDF3AF4D82486516244FCC975A8D54B441D09C83A61DADBC8736'
]
)
]