Pragmatic view on Directive 1999/93/EC

and its implementation

Paweł Krawczykpawel.krawczyk@hush.com

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 IlliteracySource: The Standish Group, „Chaos Report”, 1995

„Key success factors for eSignatures”

Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010

„Key success factors for eSignatures”

Source: Study on Cross-Border Interoperability of eSignatures (CROBIES), 2010

Complete requirements?

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

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?

Process security requirements

A B C

Examples

• Parol agreement• Written agreement• …with initials on each page• …with witness• …at notary

Temptation for single technique?

STR

EN

GTH

Single security mechanism

A B C

ADJUST FOR HIGHEST SECURITY !!!

Overkill for others

A B C

OVERKILL !OVERKILL !

Raaapiiiid….

• (8) Rapid technological development

T0 1999 Directive

T+2 2001 Polish act T+3 2002 Polish technical

Raaapiiiid….

• (8) Rapid technological development

T+5 2004 CEN still working on CWA

T+6 2005 Polish IT(„QES only”)

T+9 2008 Forced QESpurchases

Raaapiiiid….

• (8) Rapid technological development

T+10 2009/767/ECSingle point of contact, TSL„risk assessment” !

T+12 2011/130/EUReference ES formatPublic consultation on 1999/93/EC

My forecast up to 2020

• (8) Rapid technological development

2012 EC completessummary of public consultation

2020 What was that 1999/93/EC all about ???

2015 Reports, analyses…

At the same timein 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

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 QESSource: Michał Macierzyński, „Najbezpieczniejsze banki internetowe w Polsce”, Bankier.pl, 2009

Banking security evolution

2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Banking security evolution

2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Banking security evolution

2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2001 2002 2003 2004 2005 2006 2007 2008 2009 20100

2000

4000

6000

8000

10000

Electronic access to public administration services (dotted) and commercial banking services (solid)

in Poland

Year

NU

mb

er o

f u

sers

(th

ou

san

ds)

1. Electronic signatureact of 2001, plus technicalregulations 2002

2. Information technologyact of 2005

3. QES becomes mandatoryfor companies 2008

2001 2002 2003 2004 2005 2006 2007 2008 2009 20100

2000

4000

6000

8000

10000

Electronic access to public administration services (dotted) and commercial banking services (solid)

in Poland

Year

NU

mb

er o

f u

sers

(th

ou

san

ds)

Electronic banking~30% population

Publicadministration~1%

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)

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

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…

Source: CWA 14170:2004, section 5.6

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?

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)

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

Devaluation of „secure”

• 2005• Proof of concept• Malware interferes between SCA and

SSCD

Source: G DATA press release, 4 Oct 2005, Bankier.pl

Secure becomes „secure”

Source: Certum press release, Certum.pl 3 Oct 2005

Secure becomes „secure”

Source: Certum press release, Certum.pl 3 Oct 2005

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)

Interoperability

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

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

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 Finance14 EBF EBF XAdES Forms ebStream

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

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 IlliteracySource: The Standish Group, „Chaos Report”, 1995