[mender] support for secure element

15 views
Skip to first unread message

Antonio Santagiuliana

unread,
Feb 6, 2019, 9:46:57 AM2/6/19
to men...@lists.mender.io
Hello
Do you know if it is possible in some way to use Mender on the client in conjunction with some "secure storage" chip on the device ? 

These chips are usually connected to the host processor by I2Cbus and they provide help in TLS authentication, in conjunction with mbedTLS or OpenSSL software or other software that completes the whole TLS, the main point is to avoid storing on the main flash memory the private key and eventually also the pre-shared public key of the server to connect to. 
It is my understanding that Mender uses the Go Crypto lib for the Keystore but I can see it uses private key as argument for the authentication. From the Go Crypto lib I can understand it could support this but I cannot find something "ready" to be used. Anyone knows anything more about this ?

Antonio


Eystein Måløy Stenberg

unread,
Feb 6, 2019, 1:58:24 PM2/6/19
to men...@lists.mender.io, Antonio Santagiuliana
Hi Antonio,

You are correct that storing the private key used for client
authentication on disk is the only supported mode at the moment.

Since there are so many hardware-specific ways to work with keys stored
in hardware, the approach to do this is most likely to abstract out some
API for key management and use the current on-disk key store as one
implementation. This would allow supporting various hardware keystore
"modules" by implementing this layer for each hardware API.

This is not planned for the short term from "our" side and probably
quite hardware specific. If you need this soon then I would recommend
reaching out to our services team (e.g. con...@mender.io or fill out
mender.io web form).
> --
> You received this message because you are subscribed to the Google
> Groups "Mender List mender.io" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mender+un...@lists.mender.io
> <mailto:mender+un...@lists.mender.io>.
> To post to this group, send email to men...@lists.mender.io
> <mailto:men...@lists.mender.io>.
> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.

--

Eystein

Antonio Santagiuliana

unread,
Feb 7, 2019, 4:58:54 AM2/7/19
to Eystein Måløy Stenberg, men...@lists.mender.io
Thanks for the info. 
is it correct to say that Mender doesn't use TLS with mutual authentication, but just one way authentication ? I mean it is just the device ( client ) that authenticates the server through TLS authentication , but server authenticates the devices at a later stage ( proprietary stage ), after TLS connection has been established ?
Or does Mender use full mutual TLS authentication ?

thank you

Antonio



Kristian Amlie

unread,
Feb 7, 2019, 5:04:38 AM2/7/19
to men...@lists.mender.io, Antonio Santagiuliana, Eystein Måløy Stenberg
On 07/02/2019 10:58, Antonio Santagiuliana wrote:
> Thanks for the info. 
> is it correct to say that Mender doesn't use TLS with mutual
> authentication, but just one way authentication ? I mean it is just the
> device ( client ) that authenticates the server through TLS
> authentication , but server authenticates the devices at a later stage (
> proprietary stage ), after TLS connection has been established ?
> Or does Mender use full mutual TLS authentication ?

Correct, one way TLS authentication. This is because the TLS connection
must be up and running in order to send the authentication request to
the server, and then the client is authenticated later by clicking
Accept in the UI. For this second authentication the mender-agent.pem
private key is used, which is a bare key, not a certificate.

--
Kristian

signature.asc

Antonio Santagiuliana

unread,
Feb 7, 2019, 10:12:18 AM2/7/19
to Kristian Amlie, men...@lists.mender.io, Eystein Måløy Stenberg
thank you for the clarification,
I think what you wrote matches what I have now found here : 
the authentication to the server by the client is achieved by a token sent from the client and signed by its private key, after TLS connection has been established. So If I could use a token signed by my "secure element" then I think that it could be sufficient as for the one way authentication TLS handshake ( client validates server's certificate and session key is calculated  ) the client's private key shouldn't be really involved at any point.

Antonio
Reply all
Reply to author
Forward
0 new messages