aboutsummaryrefslogtreecommitdiff
path: root/docs/design_documents/symmetric_initial_attest.rst
blob: 00642b87ec40700f51ec19d3a8c2d44fe5ca39bf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
#################################################
Symmetric key algorithm based Initial Attestation
#################################################

:Authors: David Hu
:Organization: Arm Limited
:Contact: david.hu@arm.com

************
Introduction
************

This document proposes a design of symmetric key algorithm based Initial
Attestation in TF-M.

Symmetric key algorithm based Initial Attestation
(*symmetric Initial Attestation* for short) signs and verifies Initial
Attestation Token (IAT) with a symmetric cryptography signature scheme, such as
HMAC.
It can reduce TF-M binary size and memory footprint on ultra-constrained devices
without integrating asymmetric ciphers.

This proposal follows PSA Attestation API document [1]_.

.. note ::

    As pointed out by PSA Attestation API [1]_, the use cases of Initial
    Attestation based on symmetric key algorithms can be limited due to
    the associated infrastructure costs for key management and operational
    complexities. It may also restrict the ability to interoperate with
    scenarios that involve third parties.

***************
Design overview
***************

The symmetric Initial Attestation follows the existing IAT generation sequence
for Initial Attestation based on asymmetric key algorithm
(*asymmetric Initial Attestation* for short).

As Profile Small design [2]_ requests, a configuration flag
``SYMMETRIC_INITIAL_ATTESTATION`` selects symmetric initial attestation during
build.

The top-level design is shown in :ref:`overall-diagram-figure` below.

.. _overall-diagram-figure:

.. figure:: media/symmetric_initial_attest/overall_diagram.png
    :align: center

    Overall design diagram

Symmetric Initial Attestation adds its own implementations of some steps in IAT
generation in Initial Attestation secure service. More details are covered in
`IAT generation in Initial Attestation secure service`_.

The interfaces and procedures of Initial Attestation secure service are not
affected. Refer to Initial Attestation Service Integration Guide [3]_ for
details of the implementation of Initial Attestation secure service.

Symmetric Initial Attestation invokes ``t_cose`` library to build up
``COSE_Mac0`` structure.
``COSE_Mac0`` support is added to ``t_cose`` library in TF-M since official
``t_cose`` hasn't supported ``COSE_Mac0`` yet. The design of ``COSE_Mac0``
support is covered in `COSE_Mac0 support in t_cose`_.

.. note ::

    The ``COSE_Mac0`` implementation in this proposal is a prototype only for
    Proof of Concept so far. It may be replaced after ``t_cose`` officially
    supports ``COSE_Mac0`` message.

Several HAL APIs are defined to fetch platform specific assets required by
Symmetric Initial Attestation. For example, ``tfm_plat_get_symmetric_iak()``
fetches symmetric Initial Attestation Key (IAK). Those HAL APIs are summarized
in `HAL APIs`_.

Decoding and verification of symmetric Initial Attestation is also included in
this proposal for regression test.
The test suites and IAT decoding are discussed in `TF-M Test suite`_.

``QCBOR`` library and Crypto service are also invoked. But this proposal doesn't
require any modification to either ``QCBOR`` or Crypto service. Therefore,
descriptions of ``QCBOR`` and Crypto service are skipped in this document.

****************************************************
IAT generation in Initial Attestation secure service
****************************************************

The sequence of IAT generation of symmetric Initial Attestation is shown in
:ref:`ia-service-figure` below.

.. _ia-service-figure:

.. figure:: media/symmetric_initial_attest/ia_service_flow.png
    :align: center

    Symmetric IAT generation flow in Initial Attestation secure service

In Initial Attestation secure service, symmetric Initial Attestation implements
the following steps in ``attest_create_token()``, which are different from those
of asymmetric Initial Attestation.

    - Fetch and register IAK
    - ``attest_token_start()``
    - Instance ID claims
    - ``attest_token_finish()``

If ``SYMMETRIC_INITIAL_ATTESTATION`` is selected, symmetric Initial Attestation
dedicated implementations of those steps are included in build.
Otherwise, asymmetric Initial Attestation dedicated implementations are included
instead.

Symmetric Initial Attestation implementation resides a new file
``attest_symmetric_key.c`` to handle symmetric IAK and Instance ID related
operations.
Symmetric Initial Attestation dedicated ``attest_token_start()`` and
``attest_token_finish()`` are added in ``attestation_token.c``.

The details are covered in following sections.

Register symmetric IAK
======================

Symmetric Initial Attestation dedicated ``attest_symmetric_key.c`` implements 4
major functions. The functions are listed in the table below.

.. table:: Functions in ``attest_symmetric_key.c``
    :widths: auto
    :align: center

    +-------------------------------------------------+----------------------------------------------------+
    | Functions                                       | Descriptions                                       |
    +=================================================+====================================================+
    | ``attest_register_initial_attestation_key()``   | Fetches device symmetric IAK, imports it into      |
    |                                                 | Crypto service and get the handle.                 |
    |                                                 | The handle will be used to compute the             |
    |                                                 | authentication tag of IAT.                         |
    |                                                 | Invokes HAL API ``tfm_plat_get_symmetric_iak()``   |
    |                                                 | to fetch symmetric IAK from device.                |
    |                                                 |                                                    |
    |                                                 | Refer to `HAL APIs`_ for more details.             |
    +-------------------------------------------------+----------------------------------------------------+
    | ``attest_unregister_initial_attestation_key()`` | Destroys the symmetric IAK handle after IAT        |
    |                                                 | generation completes.                              |
    +-------------------------------------------------+----------------------------------------------------+
    | ``attest_get_signing_key_handle()``             | Return the IAK handle registered in                |
    |                                                 | ``attest_register_initial_attestation_key()``.     |
    +-------------------------------------------------+----------------------------------------------------+
    | ``attest_get_instance_id()``                    | Return the Instance ID value calculated in         |
    |                                                 | ``attest_register_initial_attestation_key()``.     |
    |                                                 |                                                    |
    |                                                 | Refer to `Instance ID claim`_ for more details.    |
    +-------------------------------------------------+----------------------------------------------------+

``attest_register_initial_attestation_key()`` and
``attest_unregister_initial_attestation_key()`` share the same API declarations
with asymmetric Initial Attestation.

``attest_get_signing_key_handle()`` and ``attest_get_instance_id()`` are defined
by symmetric Initial Attestation but can be shared with asymmetric Initial
Attestation later.

.. note ::

    Only symmetric IAK for HMAC algorithm is allowed so far.

Instance ID calculation
-----------------------

In symmetric Initial Attestation, Instance ID is also calculated in
``attest_register_initial_attestation_key()``, after IAK handle is registered.
It can protect critical symmetric IAK from being frequently fetched, which
increases the risk of asset disclosure.

The Instance ID value is the output of hashing symmetric IAK raw data *twice*,
as requested in PSA Attestation API [1]_. HMAC-SHA256 may be hard-coded as the
hash algorithm of Instance ID calculation.

.. note ::

    According to RFC2104 [4]_, if a HMAC key is longer than the HMAC block size,
    the key will be first hashed. The hash output is used as the key in HMAC
    computation.

    In current design, HMAC is used to calculate the authentication tag of
    ``COSE_Mac0``. Assume that symmetric IAK is longer than HMAC block size
    (HMAC-SHA256 by default), the Instance ID is actually the HMAC key for
    ``COSE_Mac0`` authentication tag generation, if Instance ID value is the
    output of hashing IAK only *once*.
    Therefore, attackers may request an valid IAT from device and fake malicious
    ones by using Instance ID to calculate valid authentication tags, to cheat
    others.

    As a result, symmetric IAK raw data should be hashed *twice* to generate the
    Instance ID value.

The Instance ID calculation result is stored in a static buffer.
Token generation process can call ``attest_get_instance_id()`` to
fetch the data from that static buffer.

attest_token_start()
====================

Symmetric Initial Attestation dedicated ``attest_token_start()`` initializes the
``COSE_Mac0`` signing context and builds up the ``COSE_Mac0`` Header.

The workflow inside ``attest_token_start()`` is shown in
:ref:`attest-token-start-figure` below.

.. _attest-token-start-figure:

.. figure:: media/symmetric_initial_attest/attest_token_start.png
    :align: center

    Workflow in symmetric Initial Attestation ``attest_token_start()``

Descriptions of each step are listed below:

#. ``t_cose_mac0_sign_init()`` is invoked to initialize ``COSE_Mac0`` signing
   context in ``t_cose``.

#. The symmetric IAK handle is returned by ``attest_get_signing_key_handle()``.
   See the details in `Register symmetric IAK`_.

#. The symmetric IAK handle is set into ``COSE_Mac0`` signing context via
   ``t_cose_mac0_set_signing_key()``.

#. Initialize ``QCBOR`` encoder.

#. The header parameters are encoded into ``COSE_Mac0`` structure in
   ``t_cose_mac0_encode_parameters()``.

#. ``QCBOREncode_OpenMap()`` prepares for encoding the ``COSE_Mac0`` payload,
   which is filled with IAT claims.

All the ``COSE_Mac0`` functionalities in ``t_cose`` are covered in
`COSE_Mac0 support in t_cose`_.

Instance ID claim
=================

Symmetric Initial Attestation also implements Instance ID claims in
``attest_add_instance_id_claim()``.

The Instance ID value is fetched via ``attest_get_instance_id()``.
The value has already been calculated during symmetric IAK registration. See
`Instance ID calculation`_ for details.

The other steps are the same as those in asymmetric Initial Attestation
implementation. The UEID type byte is set to 0x01.

attest_token_finish()
=====================

Symmetric Initial Attestation dedicated ``attest_token_finish()`` calls
``t_cose_mac0_encode_tag()`` to calculate and encode the authentication tag of
``COSE_Mac0`` structure.

The whole COSE and CBOR encoding are completed in ``attest_token_finish()``.

The simplified flow in ``attest_token_finish()`` is shown in
:ref:`attest-token-finish-figure` below.

.. _attest-token-finish-figure:

.. figure:: media/symmetric_initial_attest/attest_token_finish.png
    :align: center

    Workflow in symmetric Initial Attestation ``attest_token_finish()``

***************************
COSE_Mac0 support in t_cose
***************************

``COSE_Mac0`` supports in ``t_cose`` in TF-M include the following major
functionalities:

    - Encoding ``COSE_Mac0`` structure
    - Decoding and verifying ``COSE_Mac0`` structure
    - HMAC computation to generate and verify authentication tag
    - Short-circuit tagging for test mode

According to RFC8152 [5]_, ``COSE_Mac0`` and ``COSE_Sign1`` have similar
structures. Therefore, the prototype follows ``COSE_Sign1`` implementation to
build up ``COSE_Mac0`` file structure and implement ``COSE_Mac0`` encoding and
decoding.

Although ``COSE_Mac0`` can share lots of data types, APIs and encoding/decoding
steps with ``COSE_Sign1`` in implementation, this prototype separates
``COSE_Mac0`` implementation from ``COSE_Sign1``. ``COSE_Mac0`` owns its
dedicated signing/verification contexts, APIs and encoding/decoding process.
The purposes of separating ``COSE_Mac0`` and ``COSE_Sign1`` are listed below

- It can keep changes to ``COSE_Sign1`` as small as possible and avoid conflicts
  with development in ``COSE_Sign1```. It can decrease conflicts if ``t_cose``
  in TF-M is synchronized with original ``t_cose`` repository later.
- ``COSE_Mac0`` and ``COSE_Sign1`` are exclusive in TF-M use cases.
  It cannot decrease TF-M memory footprint by extracting the common components
  shared by ``COSE_Mac0`` and ``COSE_Sign1`` but can make the design
  over-complicated.

.. note ::

    Only HMAC is supported in current ``COSE_Mac0`` prototype.

File structure
==============

New files are added to implement the functionalities listed above. The structure
of files is shown in the table below.

.. table:: New files in ``t_cose``
    :widths: auto
    :align: center

    +---------------------+--------------------------------+----------------------------------------------+
    | Directory           | Files                          | Descriptions                                 |
    +=====================+================================+==============================================+
    | ``src``             | ``t_cose_mac0_sign.c``         | Encode ``COSE_Mac0`` structure               |
    |                     +--------------------------------+----------------------------------------------+
    |                     | ``t_cose_mac0_verify.c``       | Decode and verify ``COSE_Mac0`` structure.   |
    +---------------------+--------------------------------+----------------------------------------------+
    | ``inc``             | ``t_cose_mac0_sign.h``         | Data type definitions and function           |
    |                     |                                | declarations of encoding and signing         |
    |                     |                                | ``COSE_Mac0`` message.                       |
    |                     +--------------------------------+----------------------------------------------+
    |                     | ``t_cose_mac0_verify.h``       | Data type definitions and function           |
    |                     |                                | declarations of verifying ``COSE_Mac0``      |
    |                     |                                | message.                                     |
    +---------------------+--------------------------------+----------------------------------------------+

Other ``t_cose`` files may also be changed to add ``COSE_Mac0`` associated data
types and function declarations.

HMAC operations are added in ``crypto_adapters/t_cose_psa_crypto.c``.
Preprocessor flags are added to select corresponding crypto for COSE message
signing and verification.

    - ``T_COSE_ENABLE_SIGN1`` selects ECDSA and Hash operations for
      ``COSE_Sign1``.
    - ``T_COSE_ENABLE_MAC0`` selects HMAC operations for ``COSE_Mac0``.

Encoding COSE_Mac0
==================

Following ``COSE_Sign1`` implementation, ``COSE_Mac0`` encoding exports similar
functions to Initial Attestation secure service.
The major functions are listed below.

Initialize signing context
--------------------------

``t_cose_mac0_sign_init()`` initializes ``COSE_Mac0`` signing context and
configures option flags and algorithm used in signing.

.. code-block:: c

    static void
    t_cose_mac0_sign_init(struct t_cose_mac0_sign_ctx *me,
                          int32_t                      option_flags,
                          int32_t                      cose_algorithm_id);

The ``COSE_Mac0`` signing context is defined as

.. code-block:: c

    struct t_cose_mac0_sign_ctx {
        /* Private data structure */
        uint8_t               protected_parameters_buffer[
                                    T_COSE_MAC0_MAX_SIZE_PROTECTED_PARAMETERS];
        struct q_useful_buf_c protected_parameters; /* The encoded protected parameters */
        int32_t               cose_algorithm_id;
        struct t_cose_key     signing_key;
        int32_t               option_flags;
        struct q_useful_buf_c kid;
        ...
    };

Set signing key
---------------

``t_cose_mac0_set_signing_key()`` sets the key used in ``COSE_Mac0`` signing.
Optional ``kid``, as a key identifer, will be encoded into ``COSE_Mac0`` Header
unprotected bucket.

.. code-block:: c

    static void
    t_cose_mac0_set_signing_key(struct t_cose_mac0_sign_ctx *me,
                                struct t_cose_key            signing_key,
                                struct q_useful_buf_c        kid);

Encode Header parameters
------------------------

``t_cose_mac0_encode_parameters()`` encodes the ``COSE_Mac0`` Header parameters
and outputs the encoded context to ``cbor_encode_ctx``.

.. code-block:: c

    enum t_cose_err_t
    t_cose_mac0_encode_parameters(struct t_cose_mac0_sign_ctx *context,
                                  QCBOREncodeContext          *cbor_encode_ctx);

Calculate and add authentication tag
------------------------------------

``t_cose_mac0_encode_tag()`` calculates the authentication tag and finishes the
``COSE_Mac0`` message.

.. code-block:: c

    enum t_cose_err_t
    t_cose_mac0_encode_tag(struct t_cose_mac0_sign_ctx *context,
                           QCBOREncodeContext          *cbor_encode_ctx);

Decoding COSE_Mac0
==================

Following ``COSE_Sign1`` implementation, ``COSE_Mac0`` decoding exports similar
functions to test suite of Initial Attestation.
The major functions are listed below.

Initialize verification context
-------------------------------

``t_cose_mac0_verify_init()`` initializes ``COSE_Mac0`` verification context and
configures option flags in verification.

.. code-block:: c

    static void
    t_cose_mac0_verify_init(struct t_cose_mac0_verify_ctx *context,
                            int32_t                        option_flags);

The ``COSE_Mac0`` verification context is defined as

.. code-block:: c

    struct t_cose_mac0_verify_ctx {
        /* Private data structure */
        struct t_cose_key     verification_key;
        int32_t               option_flags;
    };

Set verification key
--------------------

``t_cose_mac0_set_verify_key()`` sets the key for verifying ``COSE_Mac0``
authentication tag.

.. code-block:: c

    static void
    t_cose_mac0_set_verify_key(struct t_cose_mac0_verify_ctx *context,
                               struct t_cose_key              verify_key);

Decode and verify COSE_Mac0
---------------------------

``t_cose_mac0_verify()`` decodes the ``COSE_Mac0`` structure and verifies the
authentication tag.

.. code-block:: c

    enum t_cose_err_t
    t_cose_mac0_verify(struct t_cose_mac0_verify_ctx *context,
                       struct q_useful_buf_c          cose_mac0,
                       struct q_useful_buf_c         *payload,
                       struct t_cose_parameters      *parameters);

Short-circuit tagging
=====================

If ``T_COSE_OPT_SHORT_CIRCUIT_TAG`` option is enabled, ``COSE_Mac0`` encoding
will hash the ``COSE_Mac0`` content and add the hash output as an authentication
tag. It is useful when critical symmetric IAK is unavailable or cannot be
accessed, perhaps because it has not been provisioned or configured for the
particular device. It is only for test and must not be used in actual use case.
The ``kid`` parameter will either be skipped in ``COSE_Mac0`` Header.

If ``T_COSE_OPT_ALLOW_SHORT_CIRCUIT`` option is enabled, ``COSE_Mac0`` decoding
will only verify the hash output, without requiring symmetric key for
authentication tag verification.

***************
TF-M Test suite
***************

Symmetric Initial Attestation adds dedicated non-secure and secure test suites.
The test suites also follow asymmetric Initial Attestation test suites
implementation but optimize the memory footprint.
Symmetric Initial Attestation non-secure and secure test suites request Initial
Attestation secure service to generate IATs. After IATs are generated
successfully, test suites decode IATs and parse the claims.
Secure test suite also verifies the authentication tag in ``COSE_Mac0``
structure.

Symmetric Initial Attestation implements its dedicated
``attest_token_decode_validate_token()`` in ``attest_symmetric_iat_decoded.c``
to perform IAT decoding required by test suites.
If ``SYMMETRIC_INITIAL_ATTESTATION`` is selected,
``attest_symmetric_iat_decoded.c`` is included in build.
Otherwise, asymmetric Initial Attestation dedicated implementations are included
instead.

The workflow of symmetric Initial Attestation dedicated
``attest_token_decode_validate_token()`` is shown below.

.. _iat-decode-figure:

.. figure:: media/symmetric_initial_attest/iat_decode.png
    :align: center

    Workflow in symmetric Initial Attestation ``attest_token_decode_validate_token()``

If the decoding is required from secure test suite,
``attest_token_decode_validate_token()`` will fetch symmetric IAK to verify the
authentication tag in ``COSE_Mac0`` structure.
If the decoding is required from non-secure test suite,
``attest_token_decode_validate_token()`` will decode ``COSE_Mac0`` only by
setting ``T_COSE_OPT_DECODE_ONLY`` option flag. Non-secure must not access the
symmetric IAK.

********
HAL APIs
********

HAL APIs are summarized below.

Fetch device symmetric IAK
==========================

``tfm_plat_get_symmetric_iak()`` fetches device symmetric IAK.

  .. code-block:: c

    enum tfm_plat_err_t tfm_plat_get_symmetric_iak(uint8_t *key_buf,
                                                   size_t buf_len,
                                                   size_t *key_len,
                                                   psa_algorithm_t *key_alg);

  **Parameters:**

  +-------------+-----------------------------------------------------------+
  | ``key_buf`` | Buffer to store the symmetric IAK.                        |
  +-------------+-----------------------------------------------------------+
  | ``buf_len`` | The length of ``key_buf``.                                |
  +-------------+-----------------------------------------------------------+
  | ``key_len`` | The length of the symmetric IAK.                          |
  +-------------+-----------------------------------------------------------+
  | ``key_alg`` | The key algorithm. Only HMAC SHA-256 is supported so far. |
  +-------------+-----------------------------------------------------------+

It returns error code specified in ``enum tfm_plat_err_t``.

Get symmetric IAK key identifier
================================

``attest_plat_get_symmetric_iak_id()`` gets the key identifier of the symmetric
IAK as the ``kid`` parameter in COSE Header.

Optional if device doesn't install a key identifier for symmetric IAK.

  .. code-block:: c

    enum tfm_plat_err_t attest_plat_get_symmetric_iak_id(void *kid_buf,
                                                         size_t buf_len,
                                                         size_t *kid_len);

  **Parameters:**

  +-------------+-------------------------------------+
  | ``kid_buf`` | Buffer to store the IAK identifier. |
  +-------------+-------------------------------------+
  | ``buf_len`` | The length of ``kid_buf``.          |
  +-------------+-------------------------------------+
  | ``kid_len`` | The length of the IAK identifier.   |
  +-------------+-------------------------------------+

It returns error code specified in ``enum tfm_plat_err_t``.

*********
Reference
*********

.. [1] `PSA Attestation API 1.0 (ARM IHI 0085) <https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Implement/IHI0085-PSA_Attestation_API-1.0.2.pdf?revision=eef78753-c77e-4b24-bcf0-65596213b4c1&la=en&hash=E5E0353D612077AFDCE3F2F3708A50C77A74B2A3>`_

.. [2] :doc:`Trusted Firmware-M Profile Small Design </docs/design_documents/profiles/tfm_profile_small>`

.. [3] :doc:`Initial Attestation Service Integration Guide </docs/reference/services/tfm_attestation_integration_guide>`

.. [4] `HMAC: Keyed-Hashing for Message Authentication <https://tools.ietf.org/html/rfc2104>`_

.. [5] `CBOR Object Signing and Encryption (COSE) <https://tools.ietf.org/html/rfc8152>`_

----------------

*Copyright (c) 2020 Arm Limited. All Rights Reserved.*