[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss-dev] DSS services and European Signature law
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:kuehne@trustable.de] Sent: 06 February 2008 10:57 To: lists@sonnenglanz.net; dss-dev@lists.oasis-open.org Cc: veit@trustable.de 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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]