Hello Andreas,
Thanks a lot for your response. You are right that there are many more
issues to consider to be able to state whether or not a DSS implementation
meets EAL 4+. To rephrase my question, more precisely, assume we have some
device that is certified to meet the requirements of CWA 14169 that has a
"trusted path" to a local user interface. For instance, it could be a
hardware device that uses the keyboard and monitor of a computer as user
interface. Now assume an alternative device that is similar in all ways
except that it can be accessed from remotely using DSS. Would this device
qualify as an SSCD?
Pim
-----Original Message-----
From: Andreas Kuehne [mailto:]
Sent: 06 February 2008 10:57
To: ;
Cc:
Subject: Re: [dss-dev] DSS services and European Signature law
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.pd
> f
> [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-Da
> ta-Aut
> henticity.wmv
>
___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto:
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
