Re: [Cfrg] CPACE: what the "session id" is for?

[Björn Haase <[e-mail]>]

Dear Loup,

This is a good question. 

The sid originally came into the design of CPace as sort of an "artifact" and as a consequence of the security analysis in the UC framework, which requires that each independent session.is given a unique session id prior to the protocol start. An analysis in the game-based models such as FTG or ROR would not have required the nonce value.

In my analysis and after discussions with Ralf Küster's group prepending a nonce to hash inputs is important in order to get UC composability guarantees if a global single hash function is to be used, since we really need to avoid any form of "shared state" between different concurrent sessions.

Still IMO, the nonce should not be considered solely as an technicality and artifact of the proof strategy but also as an advantage and security feature.

If one composes a larger protocol which uses CPace as a substep, it needs to provide its sid value to CPace in the course of the composition and make sure that any output that is generated here will be tied to this session id. Any output of a possibly concurrently running other CPace session could not provide any valuable input to the attacker. For such a composed security protocol, the sid could be considered as to form some sort of "glue" linking the individual subblocks of the composed protocol (as e.g. used in AuCPace). 

In my opinion this could be of real-world use when designing APIs for security functionality that is internally composed together by using different subparts, such as suggested by Ran Canetti in https://mailarchive.ietf.org/arch/msg/cfrg/PBMlEarxjp5l1EPfTYamE3Y_0g4/ . 

The sid also serves for making each generator ephemeral for each session and this could be useful for mitigating side-channel analysis since the adversary has essentially only one single trace available. This "ephemeral generator G" feature that comes with the inclusion of the sid is IMO also relevant for the "quantum annoying" property.

There has also be a related post on this list https://mailarchive.ietf.org/arch/msg/cfrg/fgwMYLfaa1ZbF_UgKcurse211KE/ by Ran Canetti.

I have also tried to discuss this topic roughly in slides #53 to #58 in

https://ches.iacr.org/2019/src/slides/Day3/Session13_IOTSec/Paper2_Session13_Presentation_AuCPace_CHES2019.pdf

Your question moreover has been an important topic that Michel Abdalla and Manuel have been discussing last week regarding the security proofs. In the process of the finalization of the proceedings version of their paper https://eprint.iacr.org/2020/320 , they had the plan to discuss this topic more in depth in the text and with their co-authors.

>From this discussion with Michel and Manuel I took with me that we three agreed on the assessment that for UC composability in the Joint-State setting (and a global hash function as RO is some sort of joint state) a nonce value needs to be involved in each hash operation and, thus, also in the calculation of the generator for CPace (and TBPEKE). If I understood correctly, this was also some aspect that they planned to consider in the re-work of their Annex B regarding the TBPEKE proof (which is except for the mapping almost exactly like CPace).

For this reason, I think that it is a good idea to keep the "sid" and not purely some artifact from the proof approach.

Yours,

Björn.







Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone] | Fax: [phone]
[e-mail] |  www.conducta.endress.com 





Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 



Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 


-----Ursprüngliche Nachricht-----
Von: Cfrg <[e-mail]> Im Auftrag von Loup Vaillant-David
Gesendet: Freitag, 19. Juni 2020 18:33
An: [e-mail]
Betreff: [Cfrg] CPACE: what the "session id" is for?

>From the latest draft:

  https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-haase-cpace-01&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C919f03384285480aff6e08d8146e8b15%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637281812313363894&amp;sdata=WU6zi7uD9S6%2F9RjhsQBhfKMl6ylHH%2FS58G6rDLMQkyQ%3D&amp;reserved=0

""" Let sid be a session id byte string chosen for each protocol
""" session before protocol execution; The length len(sid) SHOULD be
""" larger or equal to 16 bytes.

""" It is RECOMMENDED sid, is generated by sampling ephemeral random
""" strings.

Unlike ZPAD, The draft doesn't explain this recommendation.
What problem may occur if we omit sid altogether?

Even if G ends up being reused across several sessions, I don't believe
there's any way to tell, because Ya and Yb are uniformly distributed if
ya and yb are indeed random. I feel like I'm missing something.

Loup.


_______________________________________________
Cfrg mailing list
[e-mail]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C919f03384285480aff6e08d8146e8b15%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637281812313363894&amp;sdata=CNbRgqbWTz%2BbifiT%2FvhFv76Z6Yejo0CfTl2gpxV0oQc%3D&amp;reserved=0