README.MD
1# uOSCORE / uEDHOC
2
3
4
5
6This repository contains C implementations for constrained (and non-constrained) devices of the IETF protocols:
7
8* [OSOCRE (RFC8613)](https://tools.ietf.org/html/rfc8613) and
9* [EDHOC (draft-ietf-lake-edhoc-15 )](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-15).
10
11Main features of uOSCORE and uEDHOC are their independence from the OS, cryptographic engine and in the case of uEDHOC transport protocol. Additionally, uOSCORE and uEDHOC use only stack memory (no heap).
12
13For more background and evaluation in terms of speed, RAM and flash requirements see our paper [The Cost of OSCORE and EDHOC for Constrained Devices](https://arxiv.org/pdf/2103.13832.pdf).
14
15## How to Build and Link
16
17* check the configurations in `makefile_config.mk` and adjust them if necessary
18* run `make`
19* link the static library `build/libuoscore-uedhoc.a` in your project
20
21## Test coverage
22* [Test coverage report uOSCORE](https://eriptic.github.io/uoscore-uedhoc/src/oscore/index.html)
23* [Test coverage report uEDHOC](https://eriptic.github.io/uoscore-uedhoc/src/edhoc/index.html)
24
25## Benchmarks
26* See [Benchmarks](benchmarks.md)
27
28## Project (Folder) Structure
29
30```
31.
32|---cddl_models/
33|---externals/
34|---inc/
35|---samples/
36|---scripts/
37|---src/
38|---test/
39|---test_vectors/
40```
41* The folder `cddl_models` contains CDDL models for all CBOR structures.
42* The folder `externals` contains the external libraries and tools as git submodules.
43* The folder `inc` contains all header file.
44* The folder `samples` contains some usage examples.
45* The folder `scripts` contains scripts for generatinc C code from CDDL models and converting the json formatted EDHOC test vectors to a C header
46* The folder `src` contains all source file.
47* The folder `test` contains automated tests.
48* The folder `test_vectors` contains tests vectors.
49
50## API and Usage Model
51
52#### uOSCORE
53
54The API of uOSCORE consists of three functions:
55* `oscore_context_init()`,
56* `coap2oscore()` and
57* `oscore2coap()`.
58
59`coap2oscore()` and `oscore2coap()` convert CoAP to OSCORE packets and vice versa. `oscore_context_init()` initializes the OSCORE security context.
60
61First, `oscore_context_init()` function needs to be called on the client and server side, then `coap2oscore()` and `oscore2coap()` are called just before sending or receiving packets over the network.
62
63<img src="oscore_usage.svg" alt="drawing" width="600"/>
64
65
66#### uEDHOC
67
68The API of uEDHOC consists of four functions:
69* `ephemeral_dh_key_gen()`
70* `edhoc_initiator_run()`,
71* `edhoc_responder_run()`,
72* `edhoc_exporter()`,
73
74`ephemeral_dh_key_gen()` is used to generate fresh ephemeral DH keys before running the protocol. This function requires a random seed suable for cryptographic purposes. `edhoc_initiator_run()` and `edhoc_responder_run() ` has to be called on the initiator and responder side respectively. They return the External Authorization data `EAD_x`, the derived shared secret `PRK_out`. `PRK_out` is used as input for `edhoc_exporter()` to derive application specific keys, e.g., OSCORE master secret and OSCORE master salt.
75
76The EDHOC protocol requires the exchange of three messages (and an optional message 4) which is independent of the underlying message transport protocol. For example [appendix-A.2 in the EDHOC specification](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-15#appendix-A.2) describes how EDHOC can be transferred over CoAP, however CoAP is not mandatory. In order to be independent of the transport protocol uEDHOC uses two callback functions which need to be implemented by the user for handling the sending and receiving of messages. These functions are:
77
78```c
79/**
80 * @brief The user should call inside this function its send function.
81 *
82 *
83 * @param sock a pointer used to identify the rx chanel,
84 * e.g. a socket handler
85 * @param data data to be send
86 */
87enum err tx(void *sock, struct byte_array *data);
88
89/**
90 * @brief The user should call inside this function its receive
91 * function. The user should copy the received data in \p data.
92 *
93 * THE USER MUST MAKE SURE THAT HE/SHE IS NOT WRITING DATA OUTSIDE THE
94 * RECEIVE BUFFER, I.E., THE LENGTH OF THE RECEIVED DATA IS SMALLER
95 * THAN \p data->len.
96 *
97 * After copying, the length of the received data should be written
98 * in \p data->len.
99 *
100 *
101 * @param sock a pointer used to identify the rx chanel,
102 * e.g. a socket handler
103 * @param data the received message must be copied here
104 */
105enum err rx(void *sock, struct byte_array *data);
106```
107
108Note that uEDHOC does not provide correlation of messages. Correlation may be handled on the transport layer completely or partially. In cases when the correlation cannot be handled by the transport protocol the edhoc message needs to be prepended with a connection identifier, that is used on the other side to determine to which session a given message belongs. In order to remain conform with the specification in the cases where the transport cannot handle correlation a connection identifier needs to be prepended in `tx()` function and removed in the `rx()` function.
109
110
111## Supported Cipher Suites
112
113##### uOSCORE
114
115| Algorithms |
116| --------------------------- |
117| AES-CCM-16-64-128, SHA-256 |
118
119##### uEDHOC
120
121
122| Suit | Algorithms |
123| ---- | -------------------------------------------------------------------------- |
124| 0 | AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256 |
125| 1 | AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256 |
126| 2 | AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256 |
127| 3 | AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256 |
128
129
130
131
132## Using Different Cryptographic Libraries or Hardware Accelerators
133
134The logic of uOSCORE and uEDHOC is independent form the cryptographic library, i.e., the cryptographic library can easily be exchanged by the user. For that the user needs to provide implementations for the functions specified in `crypto_wrapper.c`.
135
136## Preventing Nonce Reuse Attacks in OSCORE
137
138AES keys should never be used more than once with a given nonce, see [RFC5084](https://datatracker.ietf.org/doc/html/rfc5084). In order to avoid this situation, the user has 2 options while creating context structure:
139- setting `fresh_master_secret_salt = true`, when given context is new (freshly obtained e.g. with EDHOC)
140- setting `fresh_master_secret_salt = false`, when the same context is used between reboots/reconnections. In this case, the user must enable Non-volatile Memory support (see `OSCORE_NVM_SUPPORT` in `makefile_config.mk`) and implement two functions that require access to NVM (see below).
141
142Note that using NVM support is independent of the parameter above. Although it is required for using the same context multiple times, it will also be utilized (if enabled) to store context obtained with EDHOC, enabling the user to reuse it after the reboot. This behaviour is useful in situations where multiple sessions need to be stored on a device, while at the same time being able to start a completely new session with EDHOC. When such feature is not needed, `OSCORE_NVM_SUPPORT` can be disabled so only fresh sessions are acceptable.
143
144 ```c
145 /**
146 * @brief When the same OSCORE master secret and salt are reused through
147 * several reboots of the device, e.g., no fresh shared secret is
148 * derived through EDHOC (or some other method) the Sender Sequence
149 * Number MUST be stored periodically in NVM.
150 * @param nvm_key part of the context that is permitted to be used for identifying the right store slot in NVM.
151 * @param ssn SSN to be written in NVM.
152 * @retval ok or error code if storing the SSN was not possible.
153 */
154 enum err nvm_write_ssn(const struct nvm_key_t *nvm_key, uint64_t ssn);
155
156 /**
157 * @brief When the same OSCORE master secret and salt are reused through
158 * several reboots of the device, e.g., no fresh shared secret is
159 * derived through EDHOC (or some other method) the Sender Sequence
160 * Number MUST be restored from NVM at each reboot.
161 * @param nvm_key part of the context that is permitted to be used for identifying the right store slot in NVM.
162 * @param ssn SSN to be read out from NVM.
163 * @retval ok or error code if the retrieving the SSN was not possible.
164 */
165 enum err nvm_read_ssn(const struct nvm_key_t *nvm_key, uint64_t *ssn);
166 ```
167
168## Additional configuration options
169The build configuration can be adjusted in the [makefile_config.mk](makefile_config.mk).
170
){kind=link}
