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

[sasi at duck.com]

Ah ok i get it. Yes i think we should include the ble keys in the request.
So it proves to whom I am talking. That's a nice way to reduce the risk.



Thanks
Sasikumar Ganesan
https://github.com/gsasikumar/
https://www.linkedin.com/in/sasikumarganesan/
https://twitter.com/g_sasi_kumar


On Fri, Jul 14, 2023 at 7:49 PM Linker Felix <
flinker_at_inf.ethz.ch_sasi at duck.com> wrote:

> 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 verifie
> *DuckDuckGo* did not detect any trackers.
> More →
>
> <https://duckduckgo.com/-nRyBzygf6dbmeXWEg48hvkeMv6TlJ8K0m7zS7Gat6LR_1I7yDhIHmlg7ebjAWsqkjNQLRUEdzpjU2xe43uHPY5aAg>
>
> 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> 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
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> --


Thanks
Sasikumar Ganesan
https://github.com/gsasikumar/
https://www.linkedin.com/in/sasikumarganesan/
https://twitter.com/g_sasi_kumar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230717/801ddd86/attachment-0001.html>