AT%CMNG not showing hashes (and certificates cannot be read so not identified)

[kratenko]

Hello,

I am working with the nRF9160 to communicate via DTLS. It works, but managing certificates is a bit of a problem. I am using the AT%CMNG command.

First, certificates (type 1) cannot be read from the modem. This is annoying, since I do not have any private keys in the certificate (but I guess you could?).

The issue is - according to the manual (see https://infocenter.nordicsemi.com/index.jsp?topic=%2Fref_at_commands%2FREF%2Fat_commands%2Fmob_termination_ctrl_status%2Fcmng_set.html), the command is supposed to give the SHA256 digest for the entity. In fact it does not. The place where that should be, it just repeatedly sends the byte representing the entity type:

at%cmng=1
%CMNG: 0,6,"0606060606060606060606060606060606060606060606060606060606060606"
%CMNG: 111,0,"0000000000000000000000000000000000000000000000000000000000000000"
%CMNG: 111,1,"0101010101010101010101010101010101010101010101010101010101010101"
%CMNG: 111,2,"0202020202020202020202020202020202020202020202020202020202020202"
%CMNG: 2000,4,"0404040404040404040404040404040404040404040404040404040404040404"
OK

You can see it in other peoples' posts here as well, e.g.: https://devzone.nordicsemi.com/f/nordic-q-a/49766/at-cmng-1-reporting-error/198450

This is awkward, because there is no way to identify which private key or certificate is in which slot. Or am I missing anything? If this a bug, will there be a patch at any point? I am using modem FW 1.2.3, which is the most recent one.

[Øyvind]

Hello,  

The AT%CMNG=1 will print

 

%CMNG: <sec_tag>,<type>[,<sha>[,<content>]]

<sec_tag>
    Integer, 0 – 2147483647.
    Mandatory for write, read, and delete operations. Optional for list operation.
    
<type>
    0 – Root CA certificate (ASCII text)
    1 – Client certificate (ASCII text)
    2 – Client private key (ASCII text)
    3 – Pre-shared Key (PSK) (ASCII text in hexadecimal string format)
    4 – PSK identity (ASCII text)
    5 – Public Key (ASCII text)
    6 – Reserved
    Mandatory if <opcode> is write, read, or delete. Parameter <type> with the value Public Key can only be used when parameter <opcode> is delete.
    
<sha>
    String. SHA-256 digest of the entity (DER, PEM) as stored in the filesystem, 64 hexadecimal characters (representing a 256 bit vector).
    Note:
        <content> in the read response is exactly what is written, including <CR>, <LF>, and other characters. The characters outside the double quotes are part of the AT response format.
        
        Reading types 1, 2, and 3 are not supported.
        

From the output you have posted above the command prints from sec_tag 0, 111 and 2000. Sec_tag 111 has Root CA certificate (type 0), Client certificate (type 1), and Client private key (type 2). As the note states in the documentation "Reading types 1, 2, and 3 are not supported" 

What do you get if you read the tag 111

AT%CMNG=1,111

Kind regards,
Øyvind

[Øyvind]

Hello again, 

I've forwarded your inquiry to our modem team to verify the AT%CMNG output.

Kind regards,
Øyvind

[kratenko]

Hallo Øyvind,

when I do AT%CMNG=1,111 it lists only the entries with 111, which is a handy feature, but still does not give me the sha. If I to AT%CMNG=2,111,1 it just gives me "ERROR", which is what it should do, according to the manual.

I know, that it says in the manual that reading type 1 (Client certificate) is not supported. I just don't understand why this was designed this way. When I use the certificate to connect to a server via DTLS the server gets the certificate, so it is possible to read it out, no gain by denying read command.

As it stands know, when I put two client certificates into the modem, I have no way of finding out which certificate is which (other than using one to connect to an endpoint I control). But maybe I'm missing something.

What I want to do, is output my used certificate my devices Log on bootup, so that users have a way to control if what connects via DTLS is really the device they have in hand. I can of course work around the problem, by keeping the same certificate (and the sha256 fingerprint) in a second, readable location, but that seems highly impractical and can always lead to inconsistencies that also would be security issues in this case.

[Øyvind]

Hi, 

I've got some feedback from our team:

"This is a documentation bug. <passwd> and <sha> parameters in AT%CMNG are not supported in any of the released modem FW version. Customers can identify keys with <sec_tag> and <key_type>. Those parameters create an unique pair that can be used for identifying and separation of keys."

This means that what you are trying to achieve is not currently supported.

Kind regards,
Øyvind

[kratenko]

Hi Øyvind,

I'm sorry to hear that <sha> is not supported by the modem. It seems like exactly the feature you would want in that place. Now I have to build that myself on top. Plus, you cannot do that for unreadable entries.

Any feedback, why it is not allowed to read out client certificates? I'll have to store it again in a second place now, which really is not ideal for consistency.

I would love to have those topics thought about for future releases. Thanks for your replies.