• Registered: 2022-09-24
  • Posts: 12

Topic: BTLE Samples / Questions on authentication

We had been looking into the ECC-Based exchange sample for BLE:

https://github.com/wolfSSL/wolfssl-exam … change.pdf

The main questions are that we do not really understand how authentication is actually done in this sample. We understand that the
transfer of data is safely encrypted but with this implementation, everyone could exchange data with each other.

What we'd care about is a safe way to authenticate the client (using PKI and provisioned certifcate on server) so we know for sure the client is
allowed to access.

Furthermore I am confused how would we be able to validate a certificate on client side for expiration? For example the client might use
a certificate that is already expired and the server should understand that and being unable to establish a connection then.

And is it possible for someone if he'd have access to the client certificate but its expired to extend its expirationa and re-use it?

thanks a lot
Ale

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: BTLE Samples / Questions on authentication

Hi Alex,

Thanks for your interest in our BTLE security.

ECIES typically does authentication after establishing a secure connection. For example in your application code you could require the peers to each present their signed certificates before allowing anything else.

If you want to use certificates you might consider just using TLS v1.3. See: https://github.com/wolfSSL/wolfssl-exam … r/btle/tls

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2022-09-24
  • Posts: 12

Re: BTLE Samples / Questions on authentication

David,

Thanks for your reply. We wanted to avoid using TLS due the overhead and thus wanted to go the ECIES way.

Would it be feasible to do authentication via ecc signing the public exchanged keys on both sides? This seems still be be way cheaper than TLS right?

We'd, however, want to send a certificate at the end from the client to the server to verify that the client is allowed to execute certain actions on our server, does this make sense? I understand via wolfSSL we could manually verify the complete chain of certificates to understand whether the incoming certificate is valid or not.

We wanted to make sure to exchange the certificate from client -> server via an already encrypted channel as we don't use it for authentication but for understanding if the user is allowed to do certain actions means we must prevent anyone catching the certificate from the client via a MITM.

hope this all makes sense,
thanks
Alex

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: BTLE Samples / Questions on authentication

Hi Alex,

Yes that would work fine and is known as public key authentication. Just make sure you use a different key for authentication. Typically that key is generated one time and use for all future authentications. Each side would present something to sign to prove having the private key. ECC is a very good algorithm for this.

The X.509 just adds the ability to have a chain of trust, however the overhead for certificates is quite large.

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2022-09-24
  • Posts: 12

Re: BTLE Samples / Questions on authentication

David,

Yes we use different keys, unique per server / client each. We have the public key of the server installed at the client to avoid rundtroup and the client generates its key at connection for each session and lets the server know including the signature to verify authencity.

For certificates -- yes the overhead is quite big. What would be the alternative actually to have something the user could send that we could verify for authencity (without the server knowing about it) and ensuring ie the user can not change things like the expiration and such?

thanks
Alex

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: BTLE Samples / Questions on authentication

Hi Alex,

If the peer generates something "random" and asks the peer to "sign" it then you know the peer has the private key. TLS does something similar by signing the digest of the handshake messages received.

Thanks,
David Garske, wolfSSL

Share

7 Reply by alex23 (edited by alex23 2022-09-26 09:45:27)

  • Registered: 2022-09-24
  • Posts: 12

Re: BTLE Samples / Questions on authentication

David,

Thank you so much. Last question on this topic promised so I really get this right please forgive me ;-)

We want to authenticate the client on the server. The server holds the public key of the client.

The client generates a new session key via wc_ecc_make_key()
Then it creates a sha256 hash out of this session key and signs it with its client key via wc_ecc_sign_hash()

The server receives both the session key plain text and the signature. It hashes the session key with sha256 and verifies the signature via wc_ecc_verify_hash() and the known client's public key the server has.

Is this a correct approach or does it have any flaws because its not the server sending random which the client signs and returns back but the client signs its own generated session key and sends it?

Thanks so much
Alex

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: BTLE Samples / Questions on authentication

Hi Alex,

This does not sound right. When you create an ECC key it generates a public and private key pair. The public portion is sent across (in the clear is fine).

The ECIES scheme itself establishes a secure channel by generating ECC keys (ephemeral / one time use), exchanging public keys and deriving a shared secret. The shared secret is then used to derive a symmetric key used for the cipher (like AES-GCM or ChaCha20/Poly1305).

If you want to authenticate in your application then on first connection you create an ECC key used for long term and provide that public key and some nonce for the peer to sign. The nonce can be random data or even a hash of the messages exchanged so far. For this to work on-going each peer should store the public key used to identify the peer as trusted. And for every connection the peer must sign something new to prove it has the private key associated with the public key.

Thanks,
David Garske, wolfSSL

Share

9 Reply by alex23 (edited by alex23 2022-09-26 22:16:07)

  • Registered: 2022-09-24
  • Posts: 12

Re: BTLE Samples / Questions on authentication

Thank you very much.

Btw we're also currently in inquiry to buy commercial licenses so this is very helpful here to solve our issue to implement it properly.

My approach was actually just following the sample code in here:

https://github.com/wolfSSL/wolfssl-exam … ver.c#L113

Where it says one should implement signing (hashing + sign) the generated public key on server side and verify that signature on client side. This is actually what I am doing just vice versa (generating the public key on client side, signing it there with my private key and the server verifying it).

Can you tell me where this is wrong or did I missunderstand the sample?

Furthermore my approach is to have one side using a static key while the other side generates a dynamic key for the session. In the example given both sides generate a dynamic/temporary key for each session. The only difference I understood from reading some documentation is that your approach provides forward secrecy and mine doesn't correct? (Reading about the ECIES they also seem to use one static key?)

However because a secret and a salt is generated for each session even with one side being a static key we still would have  forward secrecy or not?

Or should we simply go the exact route of the sample (both sides generate a temporary key) but why would the signing be required then as the code states?

And then do the authentication later over secure connection ie via a certificate sent by the client?

Sorry for those dumb questions I am trying to wrap my head around this since days and everytime I think I got it I understand I didn't ;-)

Alex

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: BTLE Samples / Questions on authentication

Hi Alex,

That comment is not very clear and I am sorry. It is referring to authentication specifically which is not handled in ECIES. The idea to hash the peers public key, sign it and send back is just an example for how to implement authentication. The important thing is to sign with a long term key, not the ephemeral key.

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2018-08-27
  • Posts: 14

Re: BTLE Samples / Questions on authentication

Hi Alex,

David asked me if I had any thoughts on this.

ECIES is about securely sending a message from the client to the server.
The client uses a server's public, along with an ephemeral key, to create a secret that becomes the encryption key for an algorithm like AES.
Only the owner of the private key corresponding to the public key used can decrypt the message.
The client does not know who the public key is for unless PKI is used.
The server does not know who the client is.

PKI is used to authenticate the owner of the public key.
A certificate wraps the public key with information that identifies the server and the a chain of certificate is used to authenticate the certificate up to a root of trust. The root of trust is a known trusted certificate.

From your postings, you want to authenticate the client.
Creating an ephemeral key and signing is not going to allow the server to authenticate the client.
Any client can send a message with any ephemeral key.
PKI, using certificates, should be used again to authenticate the client's public key.

Does any of this help?

Sean Parkinson, wolfSSL

Share

  • Registered: 2022-09-24
  • Posts: 12

Re: BTLE Samples / Questions on authentication

Sean

Thank you very much.

So I assume my initial concept should be workable reading your lines:

- Using ECIES with two temporary keys to establish a secure connection which provides also perfect forward secrecy
- Once a secure connection is established with a salt, transfer the certificate from the client
- Verify the certificate from the client server side with a trusted root certificate

However in this scenario, I can authenticate the client but not the server. My intention was to keep the public key of the server in the client and have the server send a a signature to the client based on a random hash the server sends as well and that the client verifies to authenticate the server. However, what I understand if only one key of the secure connection is temporary and the other one is static we'd loose the perfect forward secrecy correct?

I am also curious how could we safely encrypt and read permissions from a user certificate? (Create + Read it with wolfSSL).

thank you very much, thins becoming way clearer now.

Share