Hello, as suggested by Jim Schad and Mike Jones, I've written up a proposal for an additional small devices (renamed to constrained devices) use case.
I'm grateful for any comments and suggestion you may have. Regards, Ludwig Seitz -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se
5.8. Constrained Devices
This section describes use cases for constrained devices as defined
in [I-D.ietf-lwig-terminology]. Typical issues with this type of
devices are limited memory, limited power supply, low processing
power, and severe message size limitations for the communication
protocols.
5.8.1 MAC based on ECDH-derived key
A small, low power device maker has decided on using the output of
the JOSE working group as their encryption and authentication
framework. The device maker has a limited availability of both real
estate for gates and power. For this reason there are a number of
short cuts and design decisions that have been made in order to
minimize these needs.
The design team has determined that the use of message authentication
codes (MAC) is going to be sufficient to provide the necessary
authentication. However, although a MAC is going to be used, they do
not want to use a single long term shared secret. Instead they have
adopted the following proposal for computing a shared secret that can
be validated:
o An Elliptic-Curve Diffie-Hellman (ECDH) key is generated for the
device at the time of manufacturing. (Or as part of the
configuration process during installation.)
o An ECDH public key for the controller is configured at the time of
configuration.
o The configuration system performs the exponentiation and
configures the device with the resulting shared secret. This
process eliminates the need for the device to be able to perform
the required exponentiation processing. The security requirements
on protecting this computed shared secret are the same as the
requirements on protecting the private ECDH key.
o A counter and an increment value are configured onto the device.
o When a message is to be sent by the device, the counter is
incremented and a new MAC key is computed from the ECDH secret and
the counter value. A custom Key Derivation Function (KDF)
function is used when is based on the AES-CBC is used to derive
the required MAC key. The MAC key is then used to compute the MAC
value for the message.
In a similar manner the KDF function can used to compute an AEAD
algorithm key when the system needs to provide confidentially for the
message. The controller, being a larger device will perform the
exponentiation step and use a random number generator to generate the
sender nonce value.
5.8.2 Object security for CoAP
This use case deals with constrained devices of class C0/C1 (see
[I-D.ietf-lwig-terminology]). These devices communicate using RESTful
requests and responses transferred using the CoAP protocol
[I-D.ietf-core-coap]. To simplify matters, all communication is
assumed to be unicast, i.e. these security measures don't cover
multicast or broadcast.
In this type of setting it may be too costly to use session
based security (e.g. to run a 4 pass authentication protocol) since
receiving and in particular sending consumes a lot of power, in
particular for wireless devices. Therefore to just secure the CoAP
payload by replacing a plain text payload of a request or response
with a JWE object is an important alternative solution, which
allows a trade-off between protection (the CoAP headers are not
protected) and performance.
In a simple setting, consider the payload of a CoAP GET response from
a sensor type device. The information in a sensor reading may be
privacy or business sensitive and needs both integrity protection and
encryption.
However some sensor readings are very short, say a few bytes, and in
this case default encryption and integrity protection algorithms
(such as 128 bit AES with HMAC_SHA256) may cause a dramatic message
expansion of the payload, even disregarding JWE headers.
Also the value of certain sensor readings may decline rapidly, e.g.
traffic or environmental measurements, so it must be possible to
reduce the security overhead.
This leads to the following requirements which could be covered by
specific JWE/JWS profiles:
o The size of the secure object shall be as tiny as possible.
Receiving an object may cost orders of magnitude more in terms of
power than performing say public key cryptography on the object,
in particular in a wireless setting.
o Integrity protection
The object shall be able to support integrity protection, i.e. have
a field containing a digital signature, both public key signatures
and keyed message authentication codes shall be supported.
o Encryption
The object shall be able to support encryption as an optional
addition to integrity protection. It shall be possible to exclude
certain fields from encryption which are needed before verifying
integrity or decrypting the object.
o Cipher suites
It should be possible to support a variety of cipher suites to
support the constrained devices use cases. For example:
- Block ciphers with block sizes of e.g. 96 bits, in addition to
the standard 128 bits
- Modes of operation for block cihpers that do not expand the
message size to block size, e.g. GCM.
- Cipher suites that support combined encryption and MAC
calculation (i.e. AEAD modes for block ciphers).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
