[opensc-devel] Secure Messaging

2007-04-05 Thread Markus Schatzl
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

2007-04-05 Thread Andreas Schwier
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

2007-04-05 Thread Roberto Resoli

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

2007-04-05 Thread Peter Stuge
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