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

[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.

[Øyvind]

Hello, 

Can you please elaborate on how your application communicates with the modem? Have you looked at the Modem Key Management API in our Modem Libraries?

Our team responds

The private key is kept with the client instead and shall not be spread to other devices. The server confirms the authenticity of the private key and then paves the way for secure communication. For security reasons it is not allowed to read out from modem. The modem interface is designed to prevent the readback of only the private key, not the public keys or certificates. Even the root certificate can be read back using the AT commands. 

Kind regards,
Øyvind

[kratenko]

Hallo Øyvind,

sorry for the delay, I was updating my code to use the most recent version of nrf_modem, to make sure, that would not be an issue. It did not change the behaviour.

I am using AT commands only. We built our own infratructure for the 9160 from the start on, it is not relying on zephyr, so we only integrate the parts we need of the modem library.

But the second sentence in the linked documentation states: "The library uses AT commands (Credential storage management %CMNG) to add, update, and delete credentials." So I do not see how that would be an issue.

I do understand what the team says. It is good, that I cannot read the private key (type 2)! And yes, I can read the root certificate (type 0). But I cannot read the client certificate (type 1). And I do not understand why. The certificate must be public to make sense. And when I connect to the server it is sent to the server anyway, so no need in hiding it. In fact, I want to display it on every boot, so that you can verify easily that you connect end to end encrypted.

Here is a Log of what I send and the results I get (replaced some chars with * to hide our dev cert):

$ at%cmng=1
at: executing AT command on nRF9160 modem
%CMNG: 100,0,"0000000000000000000000000000000000000000000000000000000000000000"
%CMNG: 100,1,"0101010101010101010101010101010101010101010101010101010101010101"
%CMNG: 100,2,"0202020202020202020202020202020202020202020202020202020202020202"
%CMNG: 100,4,"0404040404040404040404040404040404040404040404040404040404040404"
OK
**
$ at%cmng=1,100
at: executing AT command on nRF9160 modem
%CMNG: 100,0,"0000000000000000000000000000000000000000000000000000000000000000"
%CMNG: 100,1,"0101010101010101010101010101010101010101010101010101010101010101"
%CMNG: 100,2,"0202020202020202020202020202020202020202020202020202020202020202"
%CMNG: 100,4,"0404040404040404040404040404040404040404040404040404040404040404"
OK
**
$ at%cmng=2,100,0
at: executing AT command on nRF9160 modem
%CMNG: 100,0,"0000000000000000000000000000000000000000000000000000000000000000","-----BEGIN CERTIFICATE-----
MIIByjCCAXACFGylyxbjuQukTy0WN8mvlrHc+dGTMAoGCCqGSM49BAMCMG4xCzAJ
BgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRQwEgYDVQQKDAtMb2Jhcm8gR21i
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
PQQDAgNIADBFAiBHclmqA0H7tcQD9dpxxT7Qp7BwfHlG8fgzUuXYTEAwkgIhAPv9
EDDDX+EZVzxi7MPDMBORUm6b7gjB4Z8S8PF4wqhK
-----END CERTIFICATE-----"
OK
**
$ at%cmng=2,100,1
at: executing AT command on nRF9160 modem
ERROR
**
$ at%cmng=2,100,2
at: executing AT command on nRF9160 modem
ERROR
**
$ at%cmng=2,100,4
at: executing AT command on nRF9160 modem
%CMNG: 100,4,"0404040404040404040404040404040404040404040404040404040404040404","12E9DBF8BD***********************************************E5118E6"
OK
**

This is consistent with the Documentation, but still, I do not understand why and I think it would be better changed.

[Øyvind]

Hello, I've forwarded the information to our R&D team, and will get back back to you as soon as I have an answer.

Kind regards,
Øyvind