Pragmatic view on Electronic Signature directive 1999 93

1,176 views

Published on

Discussion of legal and technical issues with EU Directive 1999/93/EC that prevented it from being adopted by European market. See http://ipsec.pl/ for more details.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,176
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 5.6 Control and possession of Signature Creation Systems

    A typical environment for the first case might be the home or the office, where the individual or the
    company has direct control of the SCS (e.g. an SCS implemented in a mobile phone). In this case, the
    security requirements may be met by organisational methods put in place or managed by the signer, and
    the technical means to ensure achievement of the security requirements may be more relaxed. For
    instance, in an extreme case, the Signer can use an isolated PC that is stored in a safe that can only be
    opened by the signer.

    A typical environment for the second case is where an SCS is located in a public place such as a railway
    station, bank or any other SCS that is operated by a service provider that is not necessarily related to or
    under the control of the signer. Without further technical security measures, this type of environment can
    suffer a number of other types of attack - e.g. replacement with a fake SCS. The technical requirements of
    SCSs operated in such public environments will necessarily be more stringent.

    These different environments have a different impact on the security requirements of the SCS since,
    although the overall security requirements remain the same for all SCEs as far as the signer is concerned,
    those security requirements need to be met in different ways.
  • Lots of marketing stuff about QES being „fully secure”, „impossible to fake”, „unrepudiable” etc.
  • „Secure signature” should be really understood as „secure in legal sense”
  • Because the SCA used is „non public” environment.
  • Pragmatic view on Electronic Signature directive 1999 93

    1. 1. Pragmatic view on Directive 1999/93/EC and its implementation Paweł Krawczyk pawel.krawczyk@hush.com
    2. 2. Why projects fail? • Incomplete Requirements • Lack of User Involvement • Lack of Resources • Unrealistic Expectations • Lack of Executive Support • Changing Requirements & Specifications • Lack of Planning • Didn't Need It Any Longer • Lack of IT Management • Technology Illiteracy Source: The Standish Group, „Chaos Report”, 1995
    3. 3. „Key success factors for eSignatures” Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010
    4. 4. „Key success factors for eSignatures” Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010
    5. 5. Complete requirements? • (4) Electronic communication and commerce necessitate "electronic signatures" and related services allowing data authentication – Who said that?
    6. 6. Differentiated services • (20) …national law lays down different requirements for the legal validity of hand-written signatures; whereas certificates can be used to confirm the identity of a person signing electronically; advanced electronic signatures based on qualified certificates aim at a higher level of security; – Why is it important?
    7. 7. Process security requirements A B C
    8. 8. Examples • Parol agreement • Written agreement • …with initials on each page • …with witness • …at notary Temptation for single technique? STRENGTH
    9. 9. Single security mechanism A B C ADJUST FOR HIGHEST SECURITY !!!
    10. 10. Overkill for others A B C OVERKILL !OVERKILL !
    11. 11. Raaapiiiid…. • (8) Rapid technological development T0 1999 Directive T+2 2001 Polish act T+3 2002 Polish technical
    12. 12. Raaapiiiid…. • (8) Rapid technological development T+5 2004 CEN still working on CWA T+6 2005 Polish IT („QES only”) T+9 2008 Forced QES purchases
    13. 13. Raaapiiiid…. • (8) Rapid technological development T+10 2009/767/EC Single point of contact, TSL „risk assessment” ! T+12 2011/130/EU Reference ES format Public consultation on 1999/93/EC
    14. 14. My forecast up to 2020 • (8) Rapid technological development 2012 EC completes summary of public consultation 2020 What was that 1999/93/EC all about ??? 2015 Reports, analyses…
    15. 15. At the same time in a parallel world… • 2001 UK Government Gateway – No QES • 2001 Poland electronic banking – No QES • 2005 Denmark OCES – No QES • 2009 Polish e-Taxes portal – No QES
    16. 16. E-banking security # of banks Sector preferences Authentication method Consumer Corporate SMS 15 Ease of use, adequate security Repudiation Hardware OTP token 11 High TCO Higher security, some non-repudiation Printed OTP list (TAN) 7 Basic security Repudiation Digital signature (*) 2 High TCO, difficult to use High non-repudiation Static password 0 Insecure Insecure (*) Not neccessarily QES Source: Michał Macierzyński, „Najbezpieczniejsze banki internetowe w Polsce”, Bankier.pl, 2009
    17. 17. Banking security evolution 2001 2003 2005 2007 2009 2011
    18. 18. Banking security evolution 2001 2003 2005 2007 2009 2011
    19. 19. Banking security evolution 2001 2003 2005 2007 2009 2011
    20. 20. 0 2000 4000 6000 8000 10000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 NUmberofusers(thousands) Year Electronic access to public administration services (dotted) and commercial banking services (solid) in Poland 1. Electronic signature act of 2001, plus technical regulations 2002 2. Information technology act of 2005 3. QES becomes mandatory for companies 2008
    21. 21. 0 2000 4000 6000 8000 10000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 NUmberofusers(thousands) Year Electronic access to public administration services (dotted) and commercial banking services (solid) in Poland Electronic banking ~30% population Public administration ~1%
    22. 22. Examples • 2009 Electronic delivery (QES required) – Chojnice region – 6 documents – Kraków – 4 documents – Radom – 0 documents • Ministry of Finance – 2009 90’000 (no QES) – 2010 355’000 (no QES) – 2011 953’375 (no QES, 3.4m QES)
    23. 23. E-inclusion • Haven’t we just seen 99% exclusion? „Firstly, in the legislative process, it supports the solutions which are favourable to the disfavoured groups. The examples may be found in the legal frameworks of eGovernment.” (MSWiA 2009) • Ok, what’s in reality??? Source: „eInclusion public policies in Europe”, final report, EC 2009
    24. 24. Summary • Monumentalism, theory of everything – Remember pseudonym certificates? • First came up with a tool – Then wondered how to use it – FAIL! • Result of 1999/93/EC for Poland – Delay of e-inclusion by 13 years • And growing • Now technology…
    25. 25. Source: CWA 14170:2004, section 5.6
    26. 26. Is this up-to-date? „A typical environment for the first case might be the home or the office, where the individual or the company has direct control of the SCS” (CWA 14170:2004, section 5.6) • Ever heard of computer networks?
    27. 27. Legal fiction • Polish technical requirements – „trusted channel”, „trusted path” (4.4) – But only for „public software” (2.9) • „Software used at home or office” is not „public” – So what’s left??? «Botnet» – a network of home and office PCs that have been compromised by malware and turned into „zombies” (MarkRatledge.com)
    28. 28. Electronic signature tools • What became „insecure”? – Microsoft Office, Open Office, Adobe Acrobat… • Security embedded into native format, automatic verification, integrated signining – Support ES, but no QES • What was nominated „secure”? – Applications written by QCAs – Usability at Windows 3.1 standards – Sign-a-binary-file
    29. 29. Devaluation of „secure” • 2005 • Proof of concept • Malware interferes between SCA and SSCD Source: G DATA press release, 4 Oct 2005, Bankier.pl
    30. 30. Secure becomes „secure” Source: Certum press release, Certum.pl 3 Oct 2005
    31. 31. Secure becomes „secure” Source: Certum press release, Certum.pl 3 Oct 2005
    32. 32. Reminder… „A typical environment for the first case might be the home or the office, where the individual or the company has direct control of the SCS” (CWA 14170:2004, section 5.6)
    33. 33. Interoperability • (5) The interoperability of electronic- signature products should be promoted
    34. 34. Signature formats in Poland (2005) No Fil ext File format Sig format Usage Vendor 1 SIG CMS CMS General Certum 2 SIG PKCS#7 PKCS#7 General KIR 3 SIGNET XAdES XAdES General Signet 4 SDOC CAB PKCS#7 MS Word Sigillum
    35. 35. Electronic signature formats in Poland (2008) No File ext File format Sig format Usage Vendor 1 EML S/MIME PKCS#7 universal Certum 2 ZSI XML XML-DSig UPO Zeto Białystok 3 signPro S/MIME PKCS#7 universal Sigillum 4 XML XML XML-DSig UPO Certum 5 XML XAdES XAdES universal Sigillum 6 SDOC CAB PKCS#7 DOC Sigillum 7 SIG CMS CMS universal Certum 8 SIG CMS CMS universal Sigillum 9 SIG PKCS#7 PKCS#7 universal KIR 10 SIG XAdES XAdES universal itBCG 11 P7 PKCS#7 PKCS#7 universal Sigillum 12 XAdES XAdES XAdES universal KIR 13 PDF PDF XAdES UPO Min. of Finance 14 EBF EBF XAdES Forms ebStream
    36. 36. Summary • Inadequate security requirements – Confusion on user market • No interoperability – Mess caused fully by vendors • No real objectives – Something indented to do everything is really not useful for anything • No functional thinking – Technical extremism – Legal extremism
    37. 37. Why projects fail? • Incomplete Requirements • Lack of User Involvement • Lack of Resources • Unrealistic Expectations • Lack of Executive Support • Changing Requirements & Specifications • Lack of Planning • Didn't Need It Any Longer • Lack of IT Management • Technology Illiteracy Source: The Standish Group, „Chaos Report”, 1995

    ×