[opensc-devel] Secure Messaging
Hello, I'd be interested if somebody here has practical experience with "Secure Messaging" modes in general and would be so kind to answer a few questions: In authentic as well as in combined mode, the use of symmetric ciphers seems to be the standard approach. To migitate simple MITM techniques, at least one keypair must be already integrated into ROM/EEPROM at the production/personalization stage and kept secret. As a result, SM can only be used with designated terminals from a single emitting instance (or partner organizations) that have knowledge about this secret key. This defeats interoperability as a whole and reminds me to the infamous "security by obscurity" solutions popular in former decades. Are there any practical attempts to negotiate keys for SM by use of public keys? What is the impact in terms of computation time for encrypted transfer at the moment, compared to a plain transmission? (Last info: x4) Plain signature functionality is neither time-critical and generally uses basic facilities available on nearly every token. As digital signatures slowly gain acceptance outside specialized applications, are there any ambitions to secure the card-to-terminal communication by default? Isn't it urgently necessary to use ad-hoc interoperable security routines in the light of the legal status of digital signatures within the EU? Thanks a lot for your efforts. All the best, /Markus ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
Hello Markus, Markus Schatzl schrieb: > Hello, > > I'd be interested if somebody here has practical experience with > "Secure Messaging" modes in general and would be so kind to > answer a few questions: Yes, we have. See [1] / IsoSecureChannel class for how that works. > > In authentic as well as in combined mode, the use of symmetric > ciphers seems to be the standard approach. To migitate simple MITM > techniques, at least one keypair must be already integrated into > ROM/EEPROM at the production/personalization stage and kept secret. I assume you mean protection of integrity and confidentiality. > > As a result, SM can only be used with designated terminals > from a single emitting instance (or partner organizations) > that have knowledge about this secret key. This defeats > interoperability as a whole and reminds me to the infamous > "security by obscurity" solutions popular in former decades. > > Are there any practical attempts to negotiate keys for SM by > use of public keys? Yes, there is. Google for the e-SignK / CWA 14890 draft CEN standard. This describes secure messaging based on a shared secret key or using a hybrid scheme with card verifiable certificates (CVCs) (all based on ISO 7816-4). That is the procedure used by several smart card applications (eGK, ECC). > > What is the impact in terms of computation time for encrypted > transfer at the moment, compared to a plain transmission? > (Last info: x4) Depends on the card, but x4 seems realistic. > > Plain signature functionality is neither time-critical and > generally uses basic facilities available on nearly every > token. As digital signatures slowly gain acceptance outside > specialized applications, are there any ambitions to secure the > card-to-terminal communication by default? This is what is called trusted-channel and can be found in CWA 14890 for electronic signature applications in an untrusted environment. > > Isn't it urgently necessary to use ad-hoc interoperable > security routines in the light of the legal status of digital > signatures within the EU? That is what standards are for ;-) Andreas [1] www.openscdp.org/scsh3/index.html -- -CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
Markus Schatzl ha scritto: Hello, I'd be interested if somebody here has practical experience with "Secure Messaging" modes in general and would be so kind to answer a few questions: In authentic as well as in combined mode, the use of symmetric ciphers seems to be the standard approach. To migitate simple MITM techniques, at least one keypair must be already integrated into ROM/EEPROM at the production/personalization stage and kept secret. As a result, SM can only be used with designated terminals from a single emitting instance (or partner organizations) that have knowledge about this secret key. This defeats interoperability as a whole and reminds me to the infamous "security by obscurity" solutions popular in former decades. Unfortunately, this is the way latest Italian EU - normative compliant digital signature cards are working now, AFAIK. As you said use of secure messaging by mean of a secret key makes almost impossible to develop an open solution because it leverages on "security by obscurity", and ties the card with use of manufacturer's middleware which carries the secret key. Note that all digital signature - relevant APDUS are SM protected on these cards. EU normative mandates only use of "secure path" and "secure channel" between SSCD and user terminal. (http://www.interlex.it/testi/pdf/dec030714.pdf , or better, referenced technical rules: CWA 14167-1 CWA 14167-2 CWA 14169 available here: http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/cwa/electronic+signatures.asp ) Are there any practical attempts to negotiate keys for SM by use of public keys? As someone noted in another reply, there is another very interesting CWA: in 14890-1 (Chapter 8, "Device authentication") , different schemes are proposed for SM, using symmetric key and using asymmetric one. With the asymmetric scheme, no prior knowledge of a secret key is necessary. What is the impact in terms of computation time for encrypted transfer at the moment, compared to a plain transmission? (Last info: x4) Plain signature functionality is neither time-critical and generally uses basic facilities available on nearly every token. As digital signatures slowly gain acceptance outside specialized applications, are there any ambitions to secure the card-to-terminal communication by default? Isn't it urgently necessary to use ad-hoc interoperable security routines in the light of the legal status of digital signatures within the EU? Definitely. Bye, Roberto Resoli. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
On Thu, Apr 05, 2007 at 10:03:51PM +0200, Roberto Resoli wrote: > > Are there any practical attempts to negotiate keys for SM by > > use of public keys? > > As someone noted in another reply, there is another very > interesting CWA: in 14890-1 (Chapter 8, "Device authentication"), > different schemes are proposed for SM, using symmetric key and > using asymmetric one. > With the asymmetric scheme, no prior knowledge of a secret key is > necessary. The Swedish way with NIDEL is to allow personalization only through qualified partners who can match a card against an identity. A PIN#3 is used for a special key pair used to authenticate the card to the partner, over the internet or in person. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
