Hey all - I'm just getting started with cose-c & I'm trying to figure out how to decrypt an Encrypt0 message. I'm trying to do something similar to this Python code: https://pycose.readthedocs.io/en/latest/examples.html#cose-encrypt0

I'm digging around the tests to see if I can figure this out but any starting point for loading a shared key & decrypting this type of message would be helpful. Are there any examples or code snippets to do this in C? Thanks in advance!

Aaron

The link directives listed below are currently marked PRIVATE but this adds burden to users of COSE-C that they must manually add openssl/mbedtls libraries to their own link directives. If these were switched to PUBLIC then CMake would take care of the transitive linking automatically.

Moving to bionic I think fixes the openssl 1.1 upgrade issue

Currently this runs on both push and pull requests. The issue with this is that once you have made a pull request the workflow is being run twice. Is there a way to make it only run once or should we remove the push and put it in individually before creation of the pull request?

It seems that this implementation doesn't support the COSE sign1 structure, true?

But the COSE-JAVA seems support it. So, is any plan for adding COSE sign1 to COSE-C ?

Hi,
I found a API COSE_Sign0_validate, but it require a cn_cbor* format public key. We always only have a public key like this:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAESn9zOanOXLrIMbtnBWia1th9PE9T
xOgD3r9dfkQz07+2HQ7MnkFW4UkMkbr+GuEESdi1b9mOowhXgeGpocV0AQ==
-----END PUBLIC KEY-----

Thanks:)

Hello @jimsch

make tests command result in test fail, what are the commands for correctly building cose-c ?

According to the image details the following openssl is already on the image

Version: 1.1.1 at C:\Program Files\OpenSSL\bin\openssl.exe
Version: 1.1.1d at C:\Strawberry\c\bin\openssl.exe
Version: 1.1.1f at C:\Program Files\Git\mingw64\bin\openssl.exe
Version: 1.1.1f at C:\Program Files\Git\usr\bin\openssl.exe
Version: 1.0.2j at C:\Program Files (x86)\Subversion\bin\openssl.exe

This means that the install step should be able to be removed.

When generating EC2 keys with mbedTLS, you sometime have points that are not always the same size.

My understanding is that this is because of the compressed point format used, when the number it represents starts with zeros, they are not serialized.

This make the 2 checks in mbedtls.c at line 715 and 723 fail for no good reason:
CHECK_CONDITION(p->length == cbGroup, COSE_ERR_INVALID_PARAMETER);

I reread the COSE RFC spec, and couldnt find anything about requirind the EC points to be of fixed size.

By changing the checks to:
CHECK_CONDITION(p->length <= cbGroup, COSE_ERR_INVALID_PARAMETER);
The errors go away. And its produces valid signatures.

Here is a sample of such key in cbor notation format:

{1: 2, -1: 1, -2: h'2C8D30E5F7530680F0414255AF7693119C786BFB3B51DFA0593CE36C8E19C87A', -3: h'0A724DC7AE3606697BBF66678B7E7205450A0EFAC3936643850383A66D4FAD', -4: h'DD81BD437805B6A4957D35DD530D8227B7DC6F16C81AE878D1A479BFB1439B9E', 2: "11"}

I want to use your conan package to verify and extract the content of a COSE_Sign1 document. I installed the conan package for my project.

Sorry for the very dumb question (never coded in C++ before): Which are the functions I should use? Is there any documentation or example code for this?

Hi there

As the tittle say. The words "C implementtation" in README.MD might confuse reader.

I went to track down the gcov issue so I downloaded the system on to my Ubuntu machine. I am running cmake version 3.10.2 on that system and I get the following error messages

jimsch@MyUbuntu:~/cose/cose-c/build$ cmake -DCOSE_C_USE_CONTEXT=OFF -DCOSE_C_USE_MBEDTLS=ON -DCOSE_C_COVERALLS=ON ..
Build type: Debug
-- adding GCC/Clang options
CMake Error at CMakeLists.txt:181 (add_library):
add_library cannot create ALIAS target "cn-cbor::cn-cbor" because target
"cn-cbor" is IMPORTED.

You have called ADD_LIBRARY for library cose-c without any source files. This typically indicates a problem with your CMakeLists.txt file
COVERALLS UPLOAD: OFF
-- COSE_C_INCLUDE_ENCRYPT:..........ON
-- COSE_C_INCLUDE_ENCRYPT0:.........ON
-- COSE_C_INCLUDE_MAC:..............ON
-- COSE_C_INCLUDE_MAC0:.............ON
-- COSE_C_INCLUDE_SIGN:.............ON
-- COSE_C_INCLUDE_SIGN0:............ON
-- COSE_C_INCLUDE_SIGN1:............ON
-- COSE_C_USE_CONTEXT:..............OFF
-- COSE_C_FATAL_WARNINGS:...........OFF
-- COSE_C_BUILD_TESTS:..............ON
-- COSE_C_BUILD_DOCS:...............OFF
-- COSE_C_USE_MBEDTLS:..............ON
-- COSE_C_USE_FIND_PACKAGE:.........OFF
-- COSE_C_BUILD_DUMPER:.............ON
-- CMAKE_BUILD_TYPE:................Debug
-- BUILD_SHARED_LIBS:...............ON
-- COSE_VERSION:....................0.1.0
-- Configuring incomplete, errors occurred!
See also "/home/jimsch/cose/cose-c/build/CMakeFiles/CMakeOutput.log".

The readme sounds like COSE is still in draft state. This is confusing and is potentially pointing people to the wrong versions of documents.

I am trying to create a sign1 message in detached mode. According to rfc8152 this is done by using a "nil" value for the message content. Following your example code I am inserting a node of the form

node = cn_cbor_data_create(NULL, 0, CBOR_CONTEXT_PARAM_COMMA NULL);
node->type = CN_CBOR_NULL;

for the message content in your json parser (test/json.cpp) but I cannot create a signed message because the call to COSE_Sign1_SetContent fails.

hi, there is no support for PS256 signature verification interface (COSE_Sign1). can cose-c support it ? or can I get some hints to implement it(I know little about encoding and decoding)?

Within ECDH_ComputeSecret() the use of ECKey_From() happens after the first switch block, which means that switch logic referenced below assumes that the provided key is from a CBOR decoding and not a native mbedtls key. If the key is infact a native mbedtls key the cn_cbor_mapget_int() will fail and the function will exit early even though the key is present.

Instead of switching on the CBOR content, the ECKey_From() should happen first (as is the case in other processing functions) and the switch can use the mbedtls key member useKey->grp.id.

Currently rfc8152 defines generic header parameters:
Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier
? 5 => bstr, ; IV
? 6 => bstr, ; Partial IV
? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
)
with labels in the range [1, 7]. The code maps string labels in the JSON files to those numeric values (e.g. "alg" -> 1), but some applications require custom string labels to be included in a protected headers. For example c2pa requires X.509 certificates to be stored in a header named "x5chain". This is currently not supported in COSE-C.

Hi, I see the typedefs of struct _cose* HCOSE, cose_sign1* ... in include/cose/cose.h, and then I search the whole project, but can not find the definition of them.

CMake Warning (dev) at build/_deps/project_mbedtls-src/programs/ssl/CMakeLists.txt:37 (target_sources):
Policy CMP0076 is not set: target_sources() command converts relative paths
to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
the cmake_policy command to set the policy and suppress this warning.

An interface source of target "ssl_client2" has a relative path.
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at build/_deps/project_mbedtls-src/programs/ssl/CMakeLists.txt:44 (target_sources):
Policy CMP0076 is not set: target_sources() command converts relative paths
to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
the cmake_policy command to set the policy and suppress this warning.

An interface source of target "ssl_server2" has a relative path.
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at build/_deps/project_mbedtls-src/programs/test/CMakeLists.txt:31 (target_sources):
Policy CMP0076 is not set: target_sources() command converts relative paths
to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
the cmake_policy command to set the policy and suppress this warning.

An interface source of target "query_compile_time_config" has a relative
path.
This warning is for project developers. Use -Wno-dev to suppress it.

see #93 (comment)

memory

if I do (memory sanitizer needs clang):

export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=memory
make -j
ctest --verbose

I get use-of-uninitialized-value errors and some tests fail

leak

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=leak
make -j
ctest --verbose

I get errors like LeakSanitizer: detected memory leaks and all tests fail
The same can be done with valgrind, see below

undefined

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=undefined
make -j
ctest --verbose

I get errors like runtime error: member access within misaligned address 0x55f6e7e1866c for type 'struct cn_cbor', which requires 8 byte alignment

valgrind

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_VALGRIND_MEMORY_CHECK=ON
make -j
ctest -D ExperimentalMemCheck

I get:

Total Test time (real) =  35.34 sec
-- Processing memory checking output:
1/32 MemCheck: #1: cose_test ........................   Defects: 7
2/32 MemCheck: #2: RFC8152 ..........................   Defects: 152
3/32 MemCheck: #3: aes-ccm ..........................   Defects: 10
4/32 MemCheck: #4: aes-gcm ..........................   Defects: 13
5/32 MemCheck: #5: enveloped ........................   Defects: 8
6/32 MemCheck: #6: encrypted ........................   Defects: 10
7/32 MemCheck: #7: cbc-mac ..........................   Defects: 9
8/32 MemCheck: #8: ecdsa ............................   Defects: 69
9/32 MemCheck: #9: eddsa ............................   Defects: 15
10/32 MemCheck: #10: hmac .............................   Defects: 9
11/32 MemCheck: #11: mac ..............................   Defects: 8
12/32 MemCheck: #12: mac0 .............................   Defects: 8
13/32 MemCheck: #13: hkdf-hmac-sha ....................   Defects: 9
14/32 MemCheck: #14: hkdf-aes .........................   Defects: 9
15/32 MemCheck: #15: aes-wrap .........................   Defects: 9
16/32 MemCheck: #16: ecdh-direct ......................   Defects: 108
17/32 MemCheck: #17: ecdh-wrap ........................   Defects: 155
18/32 MemCheck: #18: sign .............................   Defects: 18
19/32 MemCheck: #19: sign1 ............................   Defects: 18
20/32 MemCheck: #20: corner-cases .....................   Defects: 21
21/32 MemCheck: #21: Memory-mac-hmac ..................   Defects: 5
22/32 MemCheck: #22: Memory-mac-cbc-mac ...............   Defects: 5
23/32 MemCheck: #23: Memory-mac0 ......................   Defects: 5
24/32 MemCheck: #24: Memory-encrypt-gcm ...............   Defects: 5
25/32 MemCheck: #25: Memory-encrypt-ccm ...............   Defects: 5
26/32 MemCheck: #26: Memory-enveloped .................   Defects: 3
27/32 MemCheck: #27: Memory-ecdh ......................   Defects: 5
28/32 MemCheck: #28: Memory-aes-kw ....................   Defects: 5
29/32 MemCheck: #29: Memory-sign0 .....................   Defects: 15
30/32 MemCheck: #30: Memory-sign ......................   Defects: 15
31/32 MemCheck: #31: Memory-sign0-eddsa ...............   Defects: 8
32/32 MemCheck: #32: Memory-sign-eddsa ................   Defects: 8
MemCheck log files can be found here: ( * corresponds to test number)
/home/gocarlos/git/COSE-C/build/Testing/Temporary/MemoryChecker.*.log
Memory checking results:
Memory Leak - 745
Potential Memory Leak - 1
Uninitialized Memory Read - 3

eventually we start to think about converting to C++ to leverage start pointers/references which make memory issues a thing of the past

The source code seems to have some differences in style here and there.

I propose to use clang-format i.o. to use a common style across IDEs and platforms.

When I use the probject in mbed-studio, I need to manually create the cose_configure.h file because mbed-studio does not use cmake but it's own build system. I don't know that this needs to be reverted as one could build with cmake and them link it in as a binary, although I would need to spend time to get the right compiler used.

This is a ponder issue not a fix issue.

I have tried to clone a node that contains an array (CN_CBOR_ARRAY) as child using cn_cbor_clone() but sadly it doesn't work, there is another way to take a copy of the underlying cn_cbor object?

tinycbor released by intel looks like a well-maintained CBOR library while the original implementation of cn-cbor has been archived. So do we have a plan to migrate to use tinycbor?

There is a declaration of the COSE_Enveloped_GetContent() function but no implementation, so attempting to link a program using this function fails. I don't see any alternative mechanism to get decrypted plaintext data from an Enveloped container.

e.g EC_FromKey in mbedtls.c

It would probably make sense to remove code, which is commented out since 4 years.

@jimsch is this code needed?

The COSE-C source hasn't been updated in a while and there have been some changes to OpenSSL and Mbed-TLS APIs that break when used by COSE-C. I can attach a small diff that gets things running with library versions distributed with Ubuntu 22.04.

It is weird that a header file cose.h in include/ needs to include configure.h in src/. Application using COSE-C should only need to set COSE-C/include as header directory, but it currently needs to set COSE-C/src also.

The interface(include/) should not depend on the implementation(src/).

So, I think we should move configure.h to include/.