laurencelundblade/t_cose

Commercial quality COSE_Sign1 implementation in C for constrained environment. Works with MbtedTLS and OpenSSL Crypto.

t_cose implements enough of COSE to support CBOR Web Token, RFC 8392
and Entity Attestation Token (EAT). This is the COSE_Sign1 part of COSE, RFC 9052.

Implemented in C with minimal dependency – There are three main dependencies: 1) QCBOR, 2) A cryptographic library for ECDSA and SHA-2, 3) C99, <stdint.h>, <stddef.h>, <stdbool.h> and <string.h>. It is highly portable to different HW, OS's and cryptographic libraries. Except for some minor configuration for the cryptographic library, no #ifdefs or compiler options need to be set for it to run correctly.

Crypto Library Integration Layer – Works with different cryptographic libraries via a simple integration layer. The integration layer is kept small and simple, just enough for the use cases, so that integration is simpler. Integration layers for the OpenSSL and ARM Mbed TLS (PSA Cryptography API) cryptographic libraries are included.

Secure coding style – Uses a construct called UsefulBuf / q_useful_buf as a discipline for safe coding and handling of binary data.

Small simple memory model – Malloc is not needed. Besides the cryptographic library and payload buffer, about 600 bytes of heap/stack is needed for signing and 1500 bytes for verifying. The caller supplies the output buffer and context structures so the caller has control over memory usage making it useful for embedded implementations that have to run in small fixed memory.

Documentation

API documentation is here

Code Status

As of March 2022, the code is in good working order and the public interface has been stable for over a year.

Integration with the OpenSSL and Arm Mbed TLS cryptographic libraries is fully supported.

t_cose 1.0 only supports COSE Sign1, signing with one recipeint.

t_cose 2.0

As of August 2022, there are alpha releases of t_cose 2.0. It supports:

• COSE_Sign
• Multiple signatures
• COSE_MAC0
• COSE_Encrypt and COSE_Encrypt0
• Encryption with ECDH per RFC 9053

See the dev branch and the releases.

Building and Dependencies

Except for the crypto library set up, t_cose is very portable and should largely just work in any environment. It needs a few standard libraries and QCBOR (which is also very portable). Hence most of this section is about crypto library set up.

QCBOR

If QCBOR is installed in /usr/local, then the makefiles should find it. If not then QCBOR may need to be downloaded. The makefiles can be modified to reference it other than in /usr/local.

Supported Cryptographic Libraries

Here's three crypto library configurations that are supported. Others can be added with relative ease.

Test Crypto -- Makefile.test

This configuration should work instantly on any device and is useful to do a large amount of testing with, but can't be put to full commercial use. What it lacks is integration with an ECDSA implementation so it can't produce real ECDSA signatures. It does however produce fake signatures called "short-circuit signatures" that are very useful for testing. See header documentation for details on short-circuit sigs.

This configuration (and only this configuration) uses a bundled SHA-256 implementation (SHA-256 is simple and easy to bundle, ECDSA is not).

To build run:

make -f Makefile.test

OpenSSL Crypto -- Makefile.ossl

This OpenSSL integration supports SHA-256, SHA-384 and SHA-512 with ECDSA, EdDSA, or RSAPSS to support the COSE algorithms ES256, ES384 and ES512, PS256, PS384 and PS512. It is a full and tested integration with OpenSSL crypto.

If OpenSSL is installed in /usr/local or as a standar library, you can probably just run make:

make -f Makefile.ossl

The specific things that Makefile.ossl does is: * Links the crypto_adapters/t_cose_openssl_crypto.o into libt_cose.a * Links test/test/t_cose_make_openssl_test_key.o into the test binary * #define T_COSE_USE_OPENSSL_CRYPTO

t_cose is regularly tested against OpenSSL 1.1.1 and 3.0.

The crypto adaptor for OpenSSL is about twice the size of that for Mbed TLS because the API doesn't line up well with the needs for COSE (OpenSSL is ASN.1/DER oriented). Memory allocation is performed inside OpenSSL and in the crypto adaptation layer. This makes the OpenSSL crypto library less suitable for embedded use.

No deprecated or to-be-deprecated APIs are used.

There are several different sets of APIs in OpenSSL that can be used to implement ECDSA and hashing. The ones chosen are the most official and well-supported, however others might suit particular uses cases better. An older t_cose used some to-be-deprecated APIs and is a more efficient than this one. It is unfortunate that these APIs (ECDSA_do_sign and ECDSA_do_verify) are slated for deprecation and there is no supported alternative to those that work only with DER-encoded signatures.

There are no known problems with the code and test coverage for the adaptor is good. Not every single memory allocation failure has test coverage, but the code should handle them all correctly.

PSA Crypto -- Makefile.psa

As of March 2022, t_cose works with the PSA 1.0 Crypto API as implemented by Mbed TLS 2.x and 3.x.

This integration supports SHA-256, SHA-384 and SHA-512 with ECDSA, EdDSA or RSAPSS to support the COSE algorithms ES256, ES384 and ES512, PS256, PS384 and PS512.

If Mbed TLS is installed in /usr/local, you can probably just run make:

make -f Makefile.psa

If this doesn't work or you have Mbed TLS elsewhere edit the makefile.

The specific things that Makefile.psa does is: * Links the crypto_adapters/t_cose_psa_crypto.o into libt_cose.a * Links test/test/t_cose_make_psa_test_key.o into the test binary * #define T_COSE_USE_PSA_CRYPTO

This crypto adapter is small and simple. The adapter allocates no memory and as far as I know it internally allocates no memory. It is a good choice for embedded use.

It makes use of the 1.0 version of the PSA cryptographic API. No deprecated or to-be-deprecated functions are called (an older t_cose used some to be deprecated APIs).

It is regularly tested against the latest version 2 and version 3 of Mbed TLS, an implementation of the PSA crypto API.

Confidence in the adaptor code is high and reasonably well tested because it is simple.

General Crypto Library Strategy

The functions that t_cose needs from the crypto library are all defined in src/t_cose_crypto.h. This is a porting or adaption layer. There are no #ifdefs in the main t_cose code for different crypto libraries. When it needs a crypto function it just calls the interface defined in t_cose_crypto.h.

When integrating t_cose with a new cryptographic library, what is necessary is to write some code, an "adaptor", that implements t_cose_crypto.h using the new target cryptographic library. This can be done without changes to any t_cose code for many cryptographic libraries. See the interface documentation in t_cose_crypto.h for what needs to be implemented.

That said, there is one case where t_cose source code needs to be modified. This is for hash algorithm implementations that are linked into and run inline with t_cose and that have a context structure. In this case t_cose_crypto.h should be modified to use that context structure. Use the OpenSSL configuration as an example.

To complete the set up for a new cryptographic library and test it, a new test adaptation file is also needed. This file makes public key pairs of the correct type for use with testing. This file is usually named test/t_cose_make_xxxx_test_key.c and is linked in with the test app. The keys it makes are passed through t_cose untouched, through the t_cose_crypto.h interface into the underlying crypto.

Memory Usage

Code

Here are code sizes on 64-bit x86 optimized for size

 |                           | smallest | largest |  
 |---------------------------|----------|---------|
 | signing only              |     1500 |    2300 |
 | verification only         |     2500 |    3300 |
 | common to sign and verify |     (500)|    (800)|
 | combined                  |     3500 |    4800 |

Things that make the code smaller:

• PSA / Mbed crypto takes less code to interface with than OpenSSL
• gcc is usually smaller than llvm because stack guards are off by default
• Use only 256-bit crypto with the T_COSE_DISABLE_ESXXX options
• Disable short-circut sig debug faclity T_COSE_DISABLE_SHORT_CIRCUIT_SIGN
• Disable the content type header T_COSE_DISABLE_CONTENT_TYPE

Change in code size with spiffy decode

The encode size is as before.

Compared to the previous t_cose, the code size for decoding/verifying is reduced by about 600 bytes. However, spiffy decode functions in QCBOR are now required and they are about 2KB, so there is a net size increase of 1.4KB. But use of spiffy decode will also make other parts of the overall SW stack smaller, perhaps by a lot, so this will likely break even. For example, EAT or CWT decoding will be reduced a lot through use of spiffy decode. Basically, the more CBOR maps a SW stack has to handle, the more saving there will be from spiffy decode.

Heap and stack

Malloc is not used.

Stack usage is variable depending on the key and hash size and the stack usage by the cryptographic library that performs the hash and public key crypto functions. The maximum requirement is roughly 2KB. This is an estimate from examining the code, not an actual measurement.

Since the keys, hash outputs and signatures are stored on the stack, the stronger the security, the more stack is used. By default up to 512 bit EC is enabled. Disable 512 and 384 bit EC to reduce stack usage by about 100 bytes.

Different cryptographic libraries may have very different stack usage characteristics. For example if one use malloc rather than the stack, it will (hopefully) use less stack. The guess estimate range of usage by the cryptographic library is between 64 and 1024 bytes of stack.

Aside from the cryptographic library, the base stack use by t_cose is 500 bytes for signing and 1500 bytes for verification. With a large cryptographic library, the total is about 1500 bytes for signing and 2000 bytes for verification (for verification, the crypto library stack re uses stack used to decode header parameters so the increment isn't so large).

The design is such that only one copy of the output, the COSE_Sign1, need be in memory. It makes use of special features in QCBOR that allows contstuction of the output including the payload, using just the single output buffer to accomplish this.

A buffer to hold the signed COSE result must be passed in. It must be about 100 bytes larger than the combined size of the payload and key id for ECDSA 256. It can be allocated as the caller wishes.

Crypto library memory usage

In addition to the above memory usage, the crypto library will use some stack and/or heap memory. This will vary quite a bit by crypto library. Some may use malloc. Some may not.

The OpenSSL library does use malloc, even with ECDSA. Another implementation of ECDSA might not use malloc, as the keys are small enough.

Mixed code style

QCBOR uses camelCase and t_cose follows Arm's coding guidelines resulting in code with mixed styles. For better or worse, an Arm-style version of UsefulBuf is created and used and so there is a duplicate of UsefulBuf. The two are identical. They just have different names.

Limitations

• Most inputs and outputs must be in a continguous buffer. One exception to this is that CBOR payloads being signed can be constructed piecemeal into the output buffer and signed without using a separate buffer.
• Doesn't handle COSE string algorithm IDs. Only COSE integer algorithm IDs are handled. Thus far no string algorithm IDs have been assigned by IANA.
• No way to add custom headers when creating signed messages or process them during verification.
• Does not handle CBOR indefinite length strings (indefinite length maps and arrays are handled).
• Counter signatures are not supported.

Credit

• Paul Liétar for RSA PSS (PS256..PS512) and EdDSA
• Maik Riechert for cmake, CI and other.
• Ken Takayama for the bulk of the detached content implementation.
• Tamas Ban for lots code review comments, design ideas and porting to ARM PSA.
• Rob Coombs, Shebu Varghese Kuriakose and other ARM folks for sponsorship.
• Michael Eckel for makefile fixes.

Copyright and License

t_cose is available under the 3-Clause BSD License.

t_cose's Issues

Error validating signatures with 1.0

I've been trying to switch to 1.0 but for some reason signature validation is failing. I'm using the OpenSSL adapter. I can't see anything obvious I'm doing wrong, but I'm sure it is something simple.

The following test program demonstrates the issue (NOTE: this is not production code, doesn't clean up memory, and doesn't do certificate validation):

#include <iostream>
#include <fstream>
#include <sstream>
#include <vector>

#include <openssl/ec.h>
#include <openssl/engine.h>
#include <openssl/err.h>
#include <openssl/evp.h>
#include <t_cose/t_cose_sign1_verify.h>

int main(int argc, char *argv[])
{
  if (argc != 3)
  {
    std::cout << "Usage: " << argv[0] << " <certificate> <cose_sign1>" << std::endl;
    return 1;
  }
  std::string cert_path(argv[1]);
  std::string cose_sign1_path(argv[2]);
  
  std::ifstream cert_file(cert_path, std::ios::binary | std::ios::ate);
  if (!cert_file.good())
  {
    std::cout << "Failed to open certificate file" << std::endl;
    return 1;
  }
  std::streamsize cert_size = cert_file.tellg();
  cert_file.seekg(0, std::ios::beg);
  std::vector<char> cert_buf(cert_size);
  if (!cert_file.read(cert_buf.data(), cert_size))
  {
    std::cout << "Error reading certificate file" << std::endl;
    return 1;
  }
  
  std::ifstream cose_sign1_file(cose_sign1_path, std::ios::binary | std::ios::ate);
  if (!cose_sign1_file.good())
  {
    std::cout << "Failed to open COSE_Sign1 file" << std::endl;
    return 1;
  }
  std::streamsize cose_sign1_size = cose_sign1_file.tellg();
  cose_sign1_file.seekg(0, std::ios::beg);
  std::vector<char> cose_sign1_buf(cose_sign1_size);
  if (!cose_sign1_file.read(cose_sign1_buf.data(), cose_sign1_size))
  {
    std::cout << "Error reading COSE_Sign1 file" << std::endl;
    return 1;
  }
  
  auto buf = BIO_new_mem_buf(cert_buf.data(), cert_buf.size());
  auto cert = PEM_read_bio_X509(buf, NULL, NULL, NULL);
  if (!cert)
  {
    std::cout << "Error reading certificate" << std::endl;
    return 1;
  }
  auto pkey = X509_get_pubkey(cert);
  if (!pkey)
  {
    std::cout << "Error reading public key" << std::endl;
    return 1;
  }

  q_useful_buf_c cose_sign1;
  cose_sign1.ptr = cose_sign1_buf.data();
  cose_sign1.len = cose_sign1_buf.size();

  t_cose_key cose_key;
  cose_key.crypto_lib = T_COSE_CRYPTO_LIB_OPENSSL;
  cose_key.k.key_ptr = pkey;

  t_cose_sign1_verify_ctx verify_ctx;
  t_cose_sign1_verify_init(&verify_ctx, T_COSE_OPT_TAG_REQUIRED);
  t_cose_sign1_set_verification_key(&verify_ctx, cose_key);

  q_useful_buf_c returned_payload;
  t_cose_err_t error = t_cose_sign1_verify(&verify_ctx, cose_sign1, &returned_payload, nullptr);
  if (error)
  {
    std::cout << "Error verifying COSE_Sign1: " << error << std::endl;
    return 1;
  }

  std::cout << "Verified COSE_Sign1" << std::endl;
  return 0;
}

This fails with code 13 (T_COSE_ERR_SIG_VERIFY). In the old version (with EC_KEY) it worked. I also checked the test data against a Python library which can also validate it.

Here is the test data containing two files (COSE_Sign1 message and PEM-encoded certificate): test-data.zip

I did some minimal debugging since T_COSE_ERR_SIG_VERIFY is returned in two code paths. It is the second path after calling EVP_DigestVerify(). I also checked that the tbs hash is the same in 1.0 and before (by dumping it out), and it is. So it must be something else.

Any help is much appreciated.

no support for PS256

hi, can t_cose support PS256 signature verification algorithm(COSE_Sign1)? or can I get some hints to implement it.

Check against several version of crypto libraries

t_cose should be checked against popular released versions of mbedtls and openssl to be sure it is working with most, hopefully all, of them.

Add option to disable ES256

Useful if you only want EdDSA or RSA sign/verify.

Add AAD support to encryption and decryption

In the encrypt and decrypt interface this is just the adding of a useful_buf_c for AAD that can be NULL_USEFUL_BUF_C if not used. The implementation will be a little more work.

MAC header file tidiness

All functions, even the _private need documentation. The detached documentation can be short, just a reference to the non-detached.

The order of functions in compute should be init, set*, ..., _compute with the _private functions last.

Build error when the test access the Mbed Crypto private variables

Building t_cose fails with this error below when using latest Mbed TLS and Mbed Crypto without MBEDTLS_ALLOW_PRIVATE_ACCESS option.

$ make -f Makefile.psa
...
test/t_cose_make_psa_test_key.c: In function ‘check_for_key_pair_leaks’:
test/t_cose_make_psa_test_key.c:222:24: error: ‘mbedtls_psa_stats_t’ {aka ‘struct mbedtls_psa_stats_s’} has no member named ‘volatile_slots’; did you mean ‘private_volatile_slots’?
  222 |     return (int)(stats.volatile_slots +
      |                        ^~~~~~~~~~~~~~
      |                        private_volatile_slots
test/t_cose_make_psa_test_key.c:223:18: error: ‘mbedtls_psa_stats_t’ {aka ‘struct mbedtls_psa_stats_s’} has no member named ‘persistent_slots’; did you mean ‘private_persistent_slots’?
  223 |            stats.persistent_slots +
      |                  ^~~~~~~~~~~~~~~~
      |                  private_persistent_slots
test/t_cose_make_psa_test_key.c:224:18: error: ‘mbedtls_psa_stats_t’ {aka ‘struct mbedtls_psa_stats_s’} has no member named ‘external_slots’; did you mean ‘private_external_slots’?
  224 |            stats.external_slots +
      |                  ^~~~~~~~~~~~~~
      |                  private_external_slots
test/t_cose_make_psa_test_key.c:225:18: error: ‘mbedtls_psa_stats_t’ {aka ‘struct mbedtls_psa_stats_s’} has no member named ‘half_filled_slots’; did you mean ‘private_half_filled_slots’?
  225 |            stats.half_filled_slots +
      |                  ^~~~~~~~~~~~~~~~~
      |                  private_half_filled_slots
test/t_cose_make_psa_test_key.c:226:17: error: ‘mbedtls_psa_stats_t’ {aka ‘struct mbedtls_psa_stats_s’} has no member named ‘cache_slots’
  226 |            stats.cache_slots);
      |                 ^
make: *** [<builtin>: test/t_cose_make_psa_test_key.o] Error 1

These are introduced by this commit in Mbed TLS making several variables private.
The macro MBEDTLS_PRIVATE() append prefix private_ to each wrapped variable name if MBEDTLS_ALLOW_PRIVATE_ACCESS is not defined.

There are some options to fix this issue, I think.

• Do not allow t_cose users to use latest Mbed TLS/Crypto without the MBEDTLS_ALLOW_PRIVATE_ACCESS option
• Add CRYPTO_CONFIG_OPTS like T_COSE_DISABLE_PSA_KEY_PAIR_LEAK_TEST in Makefile.psa to skip the test

diff --git a/test/t_cose_make_psa_test_key.c b/test/t_cose_make_psa_test_key.c
index 245d4b7..cfa9e81 100644
--- a/test/t_cose_make_psa_test_key.c
+++ b/test/t_cose_make_psa_test_key.c
@@ -210,8 +210,9 @@ void free_ecdsa_key_pair(struct t_cose_key key_pair)
  */
 int check_for_key_pair_leaks()
 {
-#if defined(T_COSE_USE_PSA_CRYPTO_FROM_MBED_CRYPTO11)
-    /* No way to check for leaks with MBED Crypto 1.1 */
+#if defined(T_COSE_USE_PSA_CRYPTO_FROM_MBED_CRYPTO11) || \
+    defined(T_COSE_DISABLE_PSA_KEY_PAIR_LEAK_TEST)
+    /* No way to check for leaks with Mbed Crypto 1.1 and above 3.1 */
     return 0;
 
 #else

Add hmac algorithms to t_cose_crypto_is_algorithm_supported()

t_cose_crypto_is_algorithm_supported() is used in test code to determine at run time which tests to run. It might be good to also use it to determine which Mac0 tests to run.

Publish doxygen to github pages

It seems like a lot of effort was put into code documentation. It would be good to publish the doxygen generated website to GitHub Pages to make it easier to explore the APIs without building the docs locally first.

Test Mac0 against other/external examples and test cases

The Mac0 implementation only has tests against itself -- that it can validate what it computes. This is a convenient and necessary test, but there should be others against the output from other implementations of collections of know good examples (COSE_Sign1 is tested like this).

Some are available here: https://github.com/cose-wg/Examples/tree/master/mac0-tests

Make separate API for encryption with detached payload

The convention used for signing and MAC is to have one API for use without a detached payload and separate API for one with a detached payload. The two APIs are similar, but not the same. The same should be done for encryption and decryption.

Test against old versions of OpenSSL

Move struct t_cose_parameters back to t_cose_sign1_verify.h

Remove struct t_cose_parameters from t_cose_common.h. I don’t think it is needed anymore. Also remove all the stuff added to t_cose_common.h because it was added. Put it back in t_cose_sign1_verify.h where it exists for backwards compatibility purposes.

rename RunTests to RunTestsTCose

complete work to disable COSE_Sign1 and/or COSE_Sign

This was started in the Mac0 commit, but didn't go through and disable all COSE signing code.

t_cose_crypto_pub_key_sign() could be misleading

One can assume (misunderstand) that actually the public key is used to sign the data and not the private key.

Suggestions:

• t_cose_crypto_priv_key_sign(). It can be a good pair with t_cose_crypto_pub_key_verify()
• t_cose_crypto_sign(). An might t_cose_crypto_verify().

Interface change request for Detached Content

How about changing the interface t_cose_sign_encode_start and t_cose_sign_encode_finish in dev branch?
This is close to #34 , but now we can ignore the backward compatibility on t_cose 2.0.
It will be much simpler, and easy to implement detached content Mac and Encrypt.

Before

enum t_cose_err_t
t_cose_sign_encode_start(struct t_cose_sign_sign_ctx *me,
                         bool                         payload_is_detached,
                         QCBOREncodeContext          *cbor_encode_ctx)
{
    ...
    if(!payload_is_detached) {
        QCBOREncode_BstrWrap(cbor_encode_ctx);
    }
}

enum t_cose_err_t
t_cose_sign_encode_finish(struct t_cose_sign_sign_ctx *me,
                          struct q_useful_buf_c        aad,
                          struct q_useful_buf_c        detached_payload,
                          QCBOREncodeContext          *cbor_encode_ctx)
{
    if(q_useful_buf_c_is_null(detached_payload)) {
        /* Payload is inline, not detached */
        QCBOREncode_CloseBstrWrap2(cbor_encode_ctx, false, &signed_payload);
    } else {
        signed_payload = detached_payload;
    }
    ...
}

enum t_cose_err_t
t_cose_sign_one_short()
{
    return_value = t_cose_sign_encode_start(me, payload_is_detached, &encode_context);
    if(payload_is_detached) {
        QCBOREncode_AddNULL(&encode_context);
    } else {
        QCBOREncode_AddEncoded(&encode_context, payload);
    }
    if(!payload_is_detached) {
        payload = NULL_Q_USEFUL_BUF_C;
    }
    return_value = t_cose_sign_encode_finish(me, aad, payload, &encode_context);
}

After

enum t_cose_err_t
t_cose_sign_one_short()
{
    /*
    COSE_Sign = [
        Headers,
        payload : bstr / nil,
        signatures : [+ COSE_Signature]
    ]
    */

    /* encode `[` and `Headers` */
    return_value = t_cose_sign_encode_start(me, &encode_context);

    /* encode payload */
    if(payload_is_detached) {
        QCBOREncode_AddNULL(&encode_context);
        //XXX: no need to execute       payload = NULL_Q_USEFUL_BUF_C;
    } else {
        QCBOREncode_BstrWrap(cbor_encode_ctx);
        QCBOREncode_AddEncoded(&encode_context, payload);
        QCBOREncode_CloseBstrWrap2(cbor_encode_ctx, false, &signed_payload);
    }

    /* encode (`signatures` or `signature`) and `]` */
    return_value = t_cose_sign_encode_finish(me, aad, payload, &encode_context);
}

Should cmake config include /usr/local/include?

Add support for indefinite length strings for verification

This requires the ability to set up a memory pool allocator for the internal QCBOR encoder

Reference RFC 9052 rather than 8152 in Mac0 documentation

9052 is published!

HSS/LMS Support

Would be great if someone added a crypto adaptation layer for PQ!

Remove "sign" and "verify" terms from MAC implementation

Search the mac_compute and mac_validate files for the words "sign" and "verify" and you'll find lots. Many are cut-paste left overs from cloning the signing code. Most should probably changed. This includes documentation, variable names and a little other.

For example "signing_key" should probably be "mac_key" and "verify_key" should be "validate_key".

Test with indefinite length maps and arrays

Except for the TBS bytes, COSE should allow all arrays and maps to be indefinite length.

Makefile 'install' targets depend on 'all' target (including tests)

The Makefile 'install' targets ('install' and 'install_so') depend on the 'all' target, which includes tests.
I think this is not necessary and not everyone wants that. If you just want to compile and install the library (headers, *.a, and *.so), like myself, then no tests are needed.

HMAC validate and compute might not share the same context.

Not sure all crypto libraries will use the same context for mac_validate and mac_compute like PSA. It is probably not a safe assumption. Perhaps look at what OpenSSL does. Probably need to have two t_cose_crypto_hmac_update() functions, one for compute and one for validate because not all crypto may be the same as PSA

Error codes in t_cose_sign_sign.c

t_cose_sign_encode_start() in t_cose_sign_sign.c lists error codes in

t_cose/src/t_cose_sign_sign.c

Line 45 in 240b048

return_value = 888;

t_cose/src/t_cose_sign_sign.c

Line 60 in 240b048

return_value = 999;

It would be better to define the error codes in t_cose_common.h.

Add Mac0 support for OSSL crypto adaptor

Make COSE_Recipient a full public "object"

The COSE_Recipient API for both encryption and decryption should be a fully public object the way COSE_Signature is. There should be two objects, one for HPKE and one for KW.

Allow access of protected header, payload, and signature as byte strings

Being able to access protected header, payload, and signature bytes is useful for implementing things like countersignature validation in external libraries.

For inspiration, this is how go-cose exposes headers both decoded and as bytes: https://pkg.go.dev/github.com/veraison/go-cose#Headers
And here the overall structure: https://pkg.go.dev/github.com/veraison/go-cose#Sign1Message

Add `CONTRIBUTING.md`

New contributors should have a single place to go to for understanding how the project works and how contributions should be made. For code contributions, this could include things like which target branch to use, what the code style is, etc.

Use the validate/compute hmac naming in the crypto adaptor layer.

Some of the function names are aligned with the PSA API naming, not with the t_cose naming for Mac0 functions.

Use q_useful_buf instead of UsefulBuf in Mac0 code

No COSE detached content support

Current t_cose seems not to support "detached content", defined in in RFC 8152 COSE section 4.1.
It sets nil (0xF6) at the payload instead of the bstr-wrapped target payload.

The latest SUIT manifest uses this functionality, and there are examples here.

Make an official 1.0 release and add security policy

After #53 and a few other checks, I want to make an official 1.0 release.

The 2.0 release will contain some major changes such as
Mac0 support
Encryption support
Custom headers support

Not sure which ones yet, will have to see what gets done.

Make encryption use the t_cose_parameter

When encryption was first created the general purpose parameter decoder/encoder wasn't ready. Now it is. Use of it will simplify the encryption code a lot.

remove enum t_cose_tbs_hash_mode_t and t_cose_tbm_payload_mode_t

We can leave this issue around for a while to see if these get used, but if they don't when 2.0 gets close to release they should be removed.

Mac0 should use t_cose_mac_add_body_header_params

This is the new way to list parameters to encode. See t_cose_sign_sign. this will get rid of the content type methods.

Finish detached and aad support for MAC0

Support for detached payloads is only partially complete. Test cases are needed for it too. Both on the compute and validate sides. It's actually pretty close as is, so not too much work.

simple memory leak

hi,

missing call to EVP_MD_CTX_free() here.

t_cose/crypto_adapters/t_cose_openssl_crypto.c

Line 624 in d5ff4e2

return T_COSE_ERR_HASH_GENERAL_FAIL;

return value and error checking in add_unprotected_parameters

Is it void or not?

Make HPKE crypto lib neutral and make it work with OpenSSL

Right now the HPKE code calls PSA directly. This should instead go through new functions in the crypto adapter for DH and HKDF. That should also result in it working with OpenSSL.

Mac0 tbm and hmac optimization?

It might reduce object code to implement create_tbm() like create_tbs_hash() where constants are used for some of the CBOR.

It may also reduce object code to have the hmac_update() crypto layer call not return anything like the hash_update() does.

Broken link

Hi,

This link is not valid anymore (mentioned in README.md):
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_guide.rst

New location of ARM's coding guidleine:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/about/coding_guide.rst

Make qcbor_decode_error_to_t_cose_error() not inline

move qcbor_decode_error_to_t_cose_error to the t_cose_util.c file. We want one copy of it for small code size, not multiple for execution speed.

Compiler warning when included from C++: "compound literals are a C99-specific feature"

This is the compiler output, in my case an error due to -Werror:

t_cose/inc/t_cose/t_cose_sign1_verify.h:423:28: error: compound literals are a C99-specific feature [-Werror,-Wc99-extensions]
    me->verification_key = T_COSE_NULL_KEY;
                           ^
t_cose/inc/t_cose/t_cose_common.h:139:6: note: expanded from macro 'T_COSE_NULL_KEY'
    ((struct t_cose_key){T_COSE_CRYPTO_LIB_UNIDENTIFIED, {0}})

Compiler is clang++ 10.

Implement Cose_Mac0

Support custom headers

Be able to add arbitrary headers when encoding and be able to call out to custom decoder when encountering an unknown header.

Avoid hard-coded paths in Doxygen config

t_cose/doxygen/t_cose_doxyfile

Line 61 in fc3a4b2

OUTPUT_DIRECTORY = /Users/lgl/Code/t_cose/docfix/doxygen

t_cose/doxygen/t_cose_doxyfile

Line 826 in fc3a4b2

INPUT = /Users/lgl/Code/t_cose/docfix/inc/t_cose

Temporary work-around:

( cat doxygen/t_cose_doxyfile ; echo "OUTPUT_DIRECTORY=" ; echo "INPUT=inc/t_cose" ) | doxygen -

Support for EdDSA

The TEEP protocol wants to allow using EdDSA (value -8 in the COSE Algorithms registry) with COSE_Sign1

Allow verification of arbitrary size protected headers

Verification limits the protected headers size to 24 bytes. This is quite large for protected headers and thus not a huge problem.

However the same technique of incremental hashing used with the payload can be used with the protected headers and the limit completely removed.