Electronic Signatures

Copyright, 2002 © Michael Sonntag

E-Mail: [email protected]: http://www.fim.uni-linz.ac.at/staff/sonntag.htm

Mag. Dipl.-Ing. Dr. Michael Sonntag

Electronic SignaturesElectronic Signatures

Legal and Technical Aspects of E-Commerce, Budapest, 7.-11.10.2002

Michael Sonntag 2Legal and Technical Aspects of E-Commerce

Questions?Questions?Please ask them immediately!

? ?

??

??


Content

Why the need? Cryptography basics

Symmetric, asymmetric, hash; types of attacks

Key distribution / Signature systems Requirements for and functions of signatures Legal requirements

EU signature directive

Implementation in Austria US Electronic Signatures Act


Why electronic signatures?

Certain contracts / acts require a signatureThese should be also available online

Secure identification of the partnerAllows prosecution in case of fraud

Create evidence of transactions E-Mail can easily be forged (or claimed to be)

Security & TrustKnow, whom you communicated with,

and be able to provide evidence accordingly


Types of attacks

System for public transmission of data must cope with the following attacks:

Eavesdropping: Reading data during transmissionManipulation: Changing data during transmissionReplay: Copying (legitimate) data and sending it againPretending different identity: Claiming to be someone elseRepudiation: Denying to have sent/received some dataDenial of service: Cutting off communicationTraffic analysis: Analyzing patterns of communication


Types of protection

The following methods can be used for protecting systems for public transmission:

Authentication: Verifying the identity of a party Isolation: Attributing rights of persons to objects and

preventing unauthorized accessEncryption: Coding of data to be unreadable without

some secret informationChecksums: Verifying no changes have been introducedSignatures: Relating identities to messagesSteganography/Anonymizers: Hiding of a message


Attacks vs. Protection

D… Detection, P…Prevention, ()…restricted/partly/certain sense

Protection

Attacks

Authenti-

cation

Isolation Encryption Checksums Signatures Stegano-

graphy

Eavesdropping (D, P) P P

Manipulation (D) (D, P) D D D P

Replay (D) D D P

Pretending different

identity

P P (D) (D) D

Repudiation (D) P

Denial of service D D, (P)

Traffic analysis (P) P


Cryptography basics:Symmetrical cryptosyst.

Symmetrical cryptography uses the same key for encryption and decryptionThis key MUST be kept secret! (Relatively) short key lengthAlways vulnerable to brute-force attackOnly knowledge of the key allows encryption

Pla

in

Cip

her P

lain

Encryption Decryption

Secret key


Cryptography basics:Asymmetrical cryptosyst.

Asymmetrical cryptography uses different (but related) keys for encryption and decryptionThe public key is really PUBLIC (directories, ...)Long key lengthMost vulnerable to new mathematical methodsEveryone can encrypt, only intended receiver decrypt

Pla

in

Cip

her P

lain

Encryption Decryption

Public key Private keyRelated


Cryptography basics:Hash functions

One-way functions (= No recreating the input)!Loss of information

» Examples: Checksums (CRC), MAC, /etc/passwd, …

Used to reduced the amount of data to be signed Problems:

Must be hard to find a document matching the hash-valueShould be rather large (at least 128 bit)

» Testing slight modifications for a matching hash-value!

DATA Hashing

Has

h

DATAX???


Cryptography basics:Encryption / Signatures

Based on asymmetric cryptographyUsually (e. g. RSA): Signing = Encryption with private

key, verification = decryption with public key» Some signature algorithms DO NOT allow encryption, e. g. DSA!

Everyone can verify the signature’s validity Two functions of a signature:

Verifying the knowledge of the private key= Identity of the signer

Checking that no later modifications took place

Problem: How do you verify the public key?


Cryptography basics:Encryption / Signatures

Certificate = Connects a public key to a personMust be from a trusted source Is usually signed itself ( Verify this signature, ...)

Different systems for distributing these certificates» See key distribution later!

Pla

in

Pla

in +

S

igna

tur

eSigning

Verification

Public keyPrivate key Related

Valid

Invalid

Plain

Certificate


Key storage(1)

Keys for encryption/signatures should be...stored encrypted to be useless if stolenon physical tokens: Much harder to loose, importance of

use is clearer if a card (or something else) is inserted immediately marked as “invalid” if lost in any wayregularly changed to avoid too large sets of dataused only for one service: Encryption OR signatures;

business OR private, door locks OR file encryption, ...

PBE: Passphrase Based EncryptionFor avoiding the hen-egg problem when encrypting keysLong (>20 characters) passwords are used as key


Key storage(2)

Important areas in life-cycle of keys + examples:» Generation: Use “real” randomness (physical generator),

who/where are they created

» Distribution: How to publish public keys/transmit secret keys

» Storage: Preventing unauthorized access (tokens, encryption; see above)

» Usage: Is the software / environment secure, viewer problem, usability

» Administration: Which key(s) are used/required for an operation

» Disposal: Secure destroying of keys, access to backups, buffers, storage for random identical keys, ...


Key distribution:Trusted channels

Easiest way of distributing keys: Trusted channelsKnown to be secure / no eavesdroppingExamples: Couriers, personal meetings

Not usable for large groups, initially unknown partners, or when in a hurry

Can NEVER be exchanged using the untrusted channel on which they shall be used later

» Except when a previous secret is shared, which is still secure

Only very rarely usedONLY possibility for Vernam cipher


Key distribution:Certificate Authorities (1)

Central authority vouches for the association of a public key to an individualDepends on the trust of the users to this authority Important to note, what the authority verifies/guarantees

» Certification policy» E. g. Certificates for signing code DO NOT guarantee

ANYTHING about the code; only the identity of the signer (which need NOT be the programmer!)

Usually under supervision by public administration

This model is used for signatures accepted by public administration in the EU E-Government


Key distribution:Certificate Authorities (2)

In theory, the hierarchy can be very deep, but in practice, it’s rather shallow:

» CA=Certification Authority

Root-CA

CA nCA 1

User 1 User n

...

...

ProgramMessage

Certificates


Key distribution:Web of Trust

No central authority; replaced by the users If you know someone personally, you sign his public

key and publish this combination This results in a chain/web of trust:

A knows&trusts B, B k&t C; therefore A knows&trusts CBased on transitivity of trustProblem, if malicious users sign keys; if trusted by a single

person, illegal certificates are introduced» Works rather well; seems to be only minor problem in practice

Might be impossible to verify the key of an unknown user Advantage: No single point of failure


Re-Signing

Electronic signatures loose their reliability over timeToday’s secure keys can be broken/forged easily in

several yearsSome signatures must be valid for long periods

» E. g. Austria: Statute of limitations 30/40 years

Contracts are still valid, but the proof is lost!

Solution:

Before method (not: certificate!) expires, a signature with a new (longer/more secure) key must be created, which includes a secure timestamp.


Systems for el. signatures

An electronic signature cannot be easily created; a whole system is neededEvery chain is only as strong as its weakest link!2048 Bit RSA are of no use if the private key is secured

with a 4 digit password!

Main problems:Technical: Signature terminals must be secure

» =Trusted hardware + trusted software

Organizational: Verifying persons for issuing certificates» Lots of trusted persons needed in any scheme

Legal: Reduction of needs for signatures» At least in Austria signature-requirements were reduced later


Requirements for signatures

What something must fulfill to be called “signature”Dependence on document: The signature cannot be

transferred to another documentUnchangeability: The document cannot be changed

anymore after the signature was createdAssociation with person: The signature is associated

with exactly one singular personVerifiability: Anybody can verify whether the signer is

the person he/she claims to beUnforgeable: Can only be created by a single person.

The signer cannot deny having signed it


Functions of signatures

What a signature should provideConclusion: Applying the signature changes the

document from draft to final status (Unchangeability)Authenticity: The signature serves as evidence that a

certain person agreed with a declaration (=the content) (Association with person, legal presumptions)

Warning: Avoiding rashness by the signer; importance of the act

Identity: Allows identifying the person (Text of signature and non-repudiability, association with person, verifyability, unforgeable)


EU Signature directive:Signatures

According to the directive, two major classes of signatures exist:

“El. signature”: Every data used for authentication» E. g. name at the end of an E-Mail

“Advanced el. signature”: Complicated, secureUnique link to signatory

» Cannot be forged

Capable of identifying the signator» Must include the name or some other characteristic

Created with means, which can be kept under sole controlLinked to data so no later changes are possible


EU Signature directive:Certificates

Two types of certificates: » “Certificate” and “Qualified certificate”

“Qualified certificate”: Adv. signa. only with these10 requirements for the certificate itself Issued by an CA for qualified certificates

» 12 requirements + lots of rules

Allows limitations of scope or value of transactionsPseudonym instead of name possibleMust contain country of CA (no central EU registry!)Additional attributes can be incorporated

» CA must explicitly verify those before issuing the certificate


EU Signature directive:Revocation

Sometimes certificates must be revokedPrivate key lost, chipcard stolen, password disclosed, ...

Technical problemsNo generally agreed upon standard; different solutionsNo offline check for revocation possible

Legal regulations (Austria):» EU: CA must provide “secure & immediate revocation service”

Must also be possible in (hand-)written formAt most after 3 hours completedTwo types: Preliminary (Lock) and final (Revocation)


EU Signature directive: Legal effects (1)

Advanced signature + qualified certificate + secure signature-creation device:Must satisfy legal requirements in same manner as

handwritten signatures on paper» Can be used as a replacement

Must be admissible as evidence in legal proceedings» But might be of less or more “value” than signatures on paper!

NO legal presumptions» Austria: Presumption that signed content is from the signator

Certificates: Admissible in proceedings and non-discrimination


EU Signature directive: Legal effects (2)

Area where el. signatures are equal to handwritten ones (and have the same effect) are open to states

Restrictions are in the E-Commerce directive: It must be possible to conclude everything electronically, exceptAll real estate contracts excluding rental rightsAll contracts requiring courts, public authorities or

professions exercising public authority (e.g. notaries)Contracts of suretyship by persons acting for purposes

outside their trade, business or professionContracts of family law or the law of succession


EU Signature directive: Liability

CA is liable to ANYONE who reasonably relied on a qualified certificate, forall information in the certificate at the time of issuing, that it is a valid qualified certificate, the signator held the private keyprivate and public key match

unless the CA proves, he did not act negligently

failure to register revocation of a certificate No liability over/outside limitations in the certificate


EU Signature directive: Requirements for CA

General reliability Ensure operation of secure and reliable directory

and revocation services Personnel with expert knowledge Trustworthy systems and products Sufficient financial resources Extensive logging of all relevant actions Informing customers

Requires a secure computing center, large organization and numerous experts Rare!


EU Signature directive: Accreditation

Purely optional A kind of “official seal” States can set higher standards than in the

directive for these CA’sAustria: Exactly the same

“Replacement” for model “no licensing required”Seal is only awarded AFTER verification!


EU Signature directive: Various

For public sector additional requirements for el. signatures can be prescribed

No prior authorization required for CA’s CA’s may operate within the whole EU Cert. from foreign CA’s are equal to national ones Special rules for data protection

» CA may collect ANY information ONLY from the subject itself

…

See the directive and the local laws/ordinances!


Implementation in Austria

RTR: Broadcast & Telecomm. Regulation Incorp.Public supervision, registration of CA’s

A-SIT: Secure Inform. Technology Center-AustriaTechnical part: Inspection of CA’s for RTRAssociation: University Graz, Ministry of Finance,

Austrian National Bank

Currently 5 CA’s; 2 offering advanced signatures Few certificates in use

Lack of applicationsOnly very recently advanced signatures available


US El. Signatures Act(1)

Much broader than EU directive, much less technicalElectronic records

» Allows electronic archiving of papers

Transferable electronic records» Person stated in evidencing system is the current owner» Single authoritative copy

Electronic signatures» = Sound, symbol, process attached to or logically associated with

a record and attached with the intent to sign the record.

Non-discrimination of bothNo invalidity solely because of electronic form!



Exemptions:Creation/Execution of wills, codicils or testamentary trustsAdoption, divorce or other matters of family lawAll commercial transactions except sales, leases, waivers

of renunciationCourt documents (orders, notices, pleadings, …)Cancellation or termination of utility services, health

insurance or life insuranceCertain notices regarding primary residences of

individuals (repossession, eviction, ...)Accompanying documents for hazardous goods



Transferable records:Prove for ownership of a right is a record

» E. g. “classic” shares, cash, …

Problem of perfect copies: » “Authoritative” copy needed» Owner / Later owner must be shown on it» System for evidencing transactions required» Actual control needed» Unalterable» Changes only possible with consent of current owner

Can be solved by signatures and trusted systems

Unknown whether actually in use or not!


Literature/Links:

EU Signature directive: 1999/93/EC, L 13/12-20 19.1.2000

EU E-Commerce directive:2000/31/EC, L 178/1-16 17.7.2000

Austrian Signature Law:SigG BgBl I Nr. 190/1999 idF BgBl I Nr. 152/2001

Austrian Signature Ordinance:SigVO BgBl II Nr. 30/2000

US El. Signature Act: http://www.dud.de/dud/documents/usesignact0608.pdf

Mayr-Schönberger/Pilz/Reiser/Schmölzer: Praxiskommentar Signaturgesetz. Wien: Orac 1999

Electronic Signatures

Documents

Transcript of Electronic Signatures