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.

1. Pragmatic view on Directive
1999/93/EC
and its implementation
Paweł Krawczyk
pawel.krawczyk@hush.com

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. „Key success factors for eSignatures”
Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010

4. „Key success factors for eSignatures”
Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010

5. Complete requirements?
• (4) Electronic communication and
commerce necessitate "electronic
signatures" and related services
allowing data authentication
– Who said that?

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. Process security requirements
A B C

8. Examples
• Parol agreement
• Written agreement
• …with initials on each page
• …with witness
• …at notary
Temptation for single technique?
STRENGTH

9. Single security mechanism
A B C
ADJUST FOR
HIGHEST SECURITY !!!

10. Overkill for others
A B C
OVERKILL !OVERKILL !

11. Raaapiiiid….
• (8) Rapid technological development
T0 1999 Directive
T+2 2001 Polish act T+3 2002 Polish technical

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. 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. 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. 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. 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. Banking security evolution
2001 2003 2005 2007 2009 2011

18. Banking security evolution
2001 2003 2005 2007 2009 2011

19. Banking security evolution
2001 2003 2005 2007 2009 2011

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. 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. 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. 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. 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. Source: CWA 14170:2004, section 5.6

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. 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. 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

30. Devaluation of „secure”
• 2005
• Proof of concept
• Malware interferes between SCA and
SSCD
Source: G DATA press release, 4 Oct 2005, Bankier.pl

31. Secure becomes „secure”
Source: Certum press release, Certum.pl 3 Oct 2005

32. Secure becomes „secure”
Source: Certum press release, Certum.pl 3 Oct 2005

33. 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)

34. Interoperability
• (5) The interoperability of electronic-
signature products should be
promoted

35. 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

36. 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

37. 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

38. 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