Re: [dss-dev] DSS services and European Signature law

[Andreas Kuehne <kuehne@trustable.de>]

Hi Pim,

thanks for raising this interesting topic !

Due to my understanding only the smart card and card reader were seen as 
a 'Signature Creation Device', the software surrounding this device is 
called 'Signature Processing Unit'. Don't know how these terms can be 
defined precisely, but usually there used this way. Of course the 
signing software is the one doing the hashing and creating of the 
signature, also its true that the software creating e.g. a document to 
be signed could / should be considered being 'Signature Processing 
Unit', but anyway ... not our job to define this.

But seeing a DSS implementation as a 'Creation Device' or as a 
'Processing Unit' it can't be evaluated "EAL 4+" just by looking at the 
interface spec ! This process usually involves detailed design, code and 
environment reviews what can't be done with the DSS spec alone. 
Nevertheless I once defined the 'German Sig law' profile to require 
complying to the german legal framework, what involves some assurance of 
security. Having a server implementing this profile, a user can be sure 
to have the requests being processed in a law compliant way. The details 
of the fulfilment of the regulations are left to the implementor. So 
there was no need to go too deep into the difficult compliance details 
...

Maybe it would be handy to have a 'EU directive compliance' profile, 
maybe the member state regulations are too divergent for a EU-profile to 
useful ... don't know.

By the way, we are building an open-sourced implementation of DSS, maybe 
some philanthropist wants to sponsor the security evaluation ?

Greetings

Andreas


>  I am looking for more information about (or references to discussions 
> on)
>  whether or not (and if yes, under which circumstances) a DSS server 
> (using
>  adequate protection for the private keys stored on it) could be 
> claimed to
>  meet the requirements of a Secure Signature Creation Device, thus 
> allowing
>  its use to create qualified electronic signatures.  This exact 
> question was
>  asked and answered during the DSS Webinar [3], but since then I've 
> found it
>  hard to find more information or references on this.
>
>  The CEN CWA 14169 "Secure signature-creation devices "EAL 4+"" [1] 
> uses a
>  concept called "trusted path". A trusted path is referred to as "an
>  encrypted channel" to exchange authentication data between the Secure
>  Signature Creation Device and the Signature Creation Application
>  implementing the Human Interface.  It is explained to be "a 
> communication
>  channel [..] that is logically distinct from other communication 
> channels
>  and provides assured identification of its end points and protection 
> of the
>  channel data from modification or disclosure".
>
>  The DSS Core TLS security binding [2] seems to meet all these 
> requirements.
>  A DSS server can also be made to provide the same hardware/software
>  protection of the TOE as other secure devices. There are some 
> differences,
>  e.g. the owner of a key cannot physically protect a DSS server 
> "device" and
>  a DSS server in a network has a different vulnerability than an 
> off-line
>  device.  Some types of Verification Authentication Data that may be
>  acceptable for cards (e.g. PIN) are weak in a network environment, but 
> if
>  the authentication requirements are set too high they greatly reduce 
> the
>  advantages of server-based signing. A DSS Server would also typically 
> not be
>  personalized (e.g. usable by only one user) as is required for an SSCD 
> type
>  2, but serve a set of users.
>
>  The CWA consistently refers to an abstract category of Signature 
> Creation
>  Devices, of which smart cards would be just a special case. However, 
> so far
>  it seems that the extension of the general concept to other types of 
> devices
>  is not very clear and some PKI guidelines in fact narrow the SSCD 
> concept
>  down and exclude devices other than smart cards explicitly.  I would 
> very
>  much appreciate any information or pointers from people on this list, 
> and
>  more general comments on the legal status of DSS in various 
> jurisdictions.
>
>  Pim
>
>  [1] 
> ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14169-00-2004-Mar.pdf
>  [2]
>  http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-cs-v1.0-r1.htm#_Toc1
>  59076100
>  [3]
>  http://www.oasis-open.org/events/webinars/2007-07-16-DSS-Assures-WS-Data-Aut
>  henticity.wmv
>


___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de


Trustable Ltd.
Niederlassung Deutschland
Ströverstr. 18 - 59427 Unna
Amtsgericht Hamm HRB 5868

Directors
Andreas Kühne
Heiko Veit

Company UK
Company No: 5218868
Registered in England and Wales