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

[sasi at duck.com]

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
> *DuckDuckGo* did not detect any trackers.
> More →
>
> <https://duckduckgo.com/-rMdmS4eIomkfuDJosMVbtXVZ7YD1t3uJttNCgIK6G8SPkaBRpxobmPQGUKqRbv_H6nmstqJZa3mrtRkrQrRstwbOzlEB6peHaD9g5BMOjCITssQOF6rXeiPFKy02Ui4L8L6_JTyuDGvOWWz4WFnCKsOtbKOLMNT88zVpxvQYZ9CwBnECpTCCmG1x8X-8gvSzA>
>
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230713/9f13ad8b/attachment.html>