<html><head></head><body><div dir="ltr">Felix <div><br></div><div>Thanks for the analysis. I agree a formal threat model would be a good starting point. so +1 from my side.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>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.</div><div><br></div><div>Step 1: Setup a replay node & capture the previous transfer.</div><div>Step 2: For the next transfer send the ephemeral keys and some other information about the wallet.</div><div>--> Attacks on this layer from wallet's perspective. </div><div> ---> 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. </div><div> ---> 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. </div><div> ---> 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.</div><div> ---> 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?</div><div>Step 3: Now both the systems have the keys exchanged & All communications from here happens over two ephemeral keys.</div><div> From here on there should be no replay possible because of the ephemeral keys or the nonce introduced in the request. </div><div><br></div><div>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. </div><div><br></div><div><br></div><div>Thanks</div><div>Sasikumar Ganesan</div><div><a href="https://github.com/gsasikumar/" target="_blank">https://github.com/gsasikumar/</a><br></div><div><a href="https://www.linkedin.com/in/sasikumarganesan/" target="_blank">https://www.linkedin.com/in/sasikumarganesan/</a></div><div><a href="https://twitter.com/g_sasi_kumar" target="_blank">https://twitter.com/g_sasi_kumar</a><br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 12, 2023 at 2:39 PM Linker Felix via Openid-specs-ab <<a href="mailto:openid-specs-ab_at_lists.openid.net_sasi@duck.com" target="_blank">openid-specs-ab_at_lists.openid.net_sasi@duck.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div style="display:none;font-size:1px;background:rgb(255,255,255);color:rgb(0,0,0);line-height:1px;max-height:0px;max-width:0px;opacity:0;overflow:hidden"> 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 </div>
</div><div><p class="MsoNormal"><span lang="DE">Hi everyone,<u></u><u></u></span></p><p class="MsoNormal"><span lang="DE"><u></u> <u></u></span></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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:<u></u><u></u></p><ul style="margin-top:0cm" type="disc"><li style="margin-left:0cm">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.<u></u><u></u></li><li style="margin-left:0cm">The standard mentions that the authorization request should be signed (<a href="https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-over-ble-1_0.html#name-payload" target="_blank">Sec 7.2</a>), 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.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">It was a lot of fun getting my hands dirty with the standard! I hope I could provide useful feedback.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks, and best,<u></u><u></u></p><p class="MsoNormal">Felix<u></u><u></u></p></div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</body></html>