<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:153961244;
mso-list-type:hybrid;
mso-list-template-ids:-1546890870 -356865508 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=DE>Hi everyone,<o:p></o:p></span></p><p class=MsoNormal><span lang=DE><o:p> </o:p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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:<o:p></o:p></p><ul style='margin-top:0cm' type=disc><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>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.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>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">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.<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It was a lot of fun getting my hands dirty with the standard! I hope I could provide useful feedback.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, and best,<o:p></o:p></p><p class=MsoNormal>Felix<o:p></o:p></p></div></body></html>