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, 

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

[Øyvind]

Hello, 

My sincere apologies for the late reply. Your issue went of my radar before the summer and have not received correct updates internally. 

The AT command documentation should have been updated in July 2021, while the support for reading client certificates was added as a feature request in October. 

Kind regards,
Øyvind

[Achim Kraus]

In my experience, there is still no "support for reading client certificates".

Not for nRF9151 LACA A0A, mfw 2.0.1 nor nRF9160 B1A mfw 1.3.6.

%CMNG - reading the device certificate