[Openid-specs-ab] Early Formal/Security Analysis "OpenID for Verifiable Presentations over BLE"

Fri Jul 14 14:03:59 UTC 2023

Hi Sasikumar,

Maybe putting the possible attack as “replay” might be bad terminology. I picture an active MITM as an attacker. As you say, the adversary sets up a BLE replay node mimicking the verifier. As soon as a victim (holding a VC) connects, they also connect to the verifier. They perform their own key exchange with the verifier and the victim. They forward the verifier nonce to the victim, and then forward the VC to the verifier.

A bit more graphically, we have the following setup:

  Verifier (sends nonce n) <=g^(v*a)=> Adversary (forwards nonce n and VC) <=g^(a*u)=> VC holder (signs VC for nonce n)

The verifier will think that they got a VC for nonce n over the channel protected by g^(v*a) and the VC holder will think that they issued the VC to the verifier over channel g^(a*u). This might give the adversary access to the venue using someone else’s ticket because the verifier sees them using their device.

I am aware that this attack is a bit involved and not too likely, but you can avert it easily by including the BLE keys in the signed authorization request. The VC holder will see that there’s a MITM (signed key will not match used key).

But writing this mail makes me think of another issue: How does the verifier know that the person in front of them is showing the ticket? Not thinking adversarially here. Imagine a huge event like a soccer game where you have 10 people standing next to each other checking tickets. There might be many collisions in session establishment. Have you thought about this? With QR codes, this problem might be avertable (every person checking tickets has their own BLE node, though I’d need to double check the spec again). It might be worth establishing that the device that someone sees in front of them is the one that established the connection to the verifier.

But it is really important to precisely defined the security requirements. What kind of authentication is needed? 

Best,

Felix

From: sasi at duck.com <sasi at duck.com> 
Sent: Thursday, July 13, 2023 7:42 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Linker Felix <flinker at inf.ethz.ch>
Subject: Re: [Openid-specs-ab] Early Formal/Security Analysis "OpenID for Verifiable Presentations over BLE"

Felix 

Thanks for the analysis. I agree a formal threat model would be a good starting point. so +1 from my side.

Your assumptions that we will validate the verifier key is valid. Either its cached or it might follow a x509 with trusted roots. While we have left that to the implementation team. 

BLE is just the transport layer. Inside we have a request created by the verifier (defined in section 7). The request has a nonce which is random and the response from the wallet should include this nonce. You are right we have not defined the signing key. How will the wallet trust the verifier? Maybe x509 ? a wallet has DID's that are cached in its temporary storage, or DID's are cached during issuance as you know who can validate the given ticket. I think we should mandate validation of the signature, But leave the actual choices to the implementers. 

On the replay part. Let us assume there is an active attacker who wants to replay the data and take out a user's session.

Step 1: Setup a replay node & capture the previous transfer.

Step 2: For the next transfer send the ephemeral keys and some other information about the wallet.

--> Attacks on this layer from wallet's perspective. 

      ---> An attacker capturing ble packets at this stage will have to modify the public ephemeral key to his own as he does not own the private key. 

      ---> In case he modifies successfully then he can take over the session (But the session has not yet started) then he can not have my VC. 

      ---> Maybe the attacker has pre-captured ble packets with preseeded ephemeral keys. In this case he would use the previous step and force his preseeded keys and nonce.

      ---> So this could possibly be a replay attack, but then the nonce as defined in the section 7 can potentially break this as the attacker has the nonce from the previous session and does not match new request nonce?

Step 3: Now both the systems have the keys exchanged & All communications from here happens over two ephemeral keys.

 From here on there should be no replay possible because of the ephemeral keys or the nonce introduced in the request. 

Am I missing anything here that you feel an attacker can break?  Also all the chunks are pre-encrypted with AES/GCM and then chunked. So any drop or change would break the GCM. 

Thanks

Sasikumar Ganesan

https://github.com/gsasikumar/

https://www.linkedin.com/in/sasikumarganesan/

https://twitter.com/g_sasi_kumar

On Wed, Jul 12, 2023 at 2:39 PM Linker Felix via Openid-specs-ab <openid-specs-ab_at_lists.openid.net_sasi at duck.com <mailto:openid-specs-ab_at_lists.openid.net_sasi at duck.com> > wrote:

Hi everyone, I briefly introduced myself 3 weeks ago in the SIOP call already. I am Felix, a PhD student in the information security group of David Basin at ETHZ. Pieter Kasselman encouraged me to joi 

Hi everyone,

I briefly introduced myself 3 weeks ago in the SIOP call already. I am Felix, a PhD student in the information security group of David Basin at ETHZ. Pieter Kasselman encouraged me to join the work on the OpenID for Verifiable Presentations over BLE standard to conduct a formal analysis of it. It took a while for me to be able to join, but now I am here and have some early thoughts to discuss.

First of all, the standard does neither mention a threat model nor desired security properties. So for the formal analysis, I just invented my own! But I would argue that it’s worth reflecting both a threat model and desired security properties in the standard. As for an attacker, I considered an active network adversary (can read, drop, re-route, replay, send any message) and assumed that the wallet can obtain an authentic public key of the verifier. I analyzed the secrecy of the shared verified credential, and injective agreement between wallet and verifier. Injective agreement here means that the wallet and verifier agree on recipient of the credential, shared BLE-layer key, nonce within VC, and the VC itself. Furthermore, there is an injective mapping from “sharing a VC” to “accepting a VC” events, i.e., no replay of tokens is possible.

During my modeling phase, I specifically wondered about the key material that should be used. (As an outcome of my head scratching, I assumed that the wallet can obtain an authentic public key of the verifier in my threat model.) In particular:

*	The standard mentions that both the wallet and verifier use ephemeral keys, but it is not specified to what extent these keys should be ephemeral. When should they be generated? I assumed, that the verifier generates a fresh key per BLE connection, and the wallet generates its key freshly when it engages in a new BLE connection.
*	The standard mentions that the authorization request should be signed (Sec 7.2 <https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-over-ble-1_0.html#name-payload> ), but not with what key, and also doesn’t specify how the wallet should verify the signature. I presume that the wallet has obtained an authentic public key of the verifier in advance as the standard assumes no connectivity. This seems to fit the scope of this standard well (when I buy a ticket, I can anticipate who will check it). Nevertheless, this (in my eyes) should be addressed.

In my analysis of the secrecy of the token, I found that an active network attacker can MITM the Bluetooth connection and forward tokens to the verifier, thus, associating a VC with their Bluetooth session. A straight-forward defense here would be to include the shared key for the BLE-layer in the signed authorization request, binding the request to the BLE channel. Have you considered this?

I have many small points on phrasing of the standard, but I think it would be futile to list them all in this mail (the mail is long enough already). Should I open an issue for this?

It was a lot of fun getting my hands dirty with the standard! I hope I could provide useful feedback.

Thanks, and best,

Felix

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net> 
https://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230714/d91248ac/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5719 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230714/d91248ac/attachment-0001.p7s>