Electronic Signatures

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

? ? 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 signature • These should be also available online • Secure identification of the partner • Allows prosecution in case of fraud • Create evidence of transactions • E-Mail can easily be forged (or claimed to be) Security & Trust Know, 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 transmission • Manipulation: Changing data during transmission • Replay: Copying (legitimate) data and sending it again • Pretending different identity: Claiming to be someone else • Repudiation: Denying to have sent/received some data • Denial of service: Cutting off communication • Traffic 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 access • Encryption: Coding of data to be unreadable without some secret information • Checksums: Verifying no changes have been introduced • Signatures: Relating identities to messages • Steganography/Anonymizers: Hiding of a message

Attacks vs. Protection D… Detection, P…Prevention, ()…restricted/partly/certain sense

Secret key Plain Plain Cipher Encryption Decryption Cryptography basics:Symmetrical cryptosyst. Symmetrical cryptography uses the same key for encryption and decryption • This key MUST be kept secret! • (Relatively) short key length • Always vulnerable to brute-force attack • Only knowledge of the key allows encryption

Public key Related Private key Plain Plain Cipher Encryption Decryption Cryptography basics:Asymmetrical cryptosyst. • Asymmetrical cryptography uses different (but related) keys for encryption and decryption • The public key is really PUBLIC (directories, ...) • Long key length • Most vulnerable to new mathematical methods • Everyone can encrypt, only intended receiver decrypt

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-value • Should be rather large (at least 128 bit) • Testing slight modifications for a matching hash-value! X Hash DATA DATA Hashing ???

Cryptography basics:Encryption / Signatures • Based on asymmetric cryptography • Usually (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 person • Must be from a trusted source • Is usually signed itself ( Verify this signature,  ...) • Different systems for distributing these certificates • See key distribution later! Certificate Private key Related Public key Valid Plain + Signature Verification Plain Invalid Signing Plain

Key storage(1) • Keys for encryption/signatures should be... • stored encrypted to be useless if stolen • on 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 way • regularly changed to avoid too large sets of data • used only for one service: Encryption OR signatures; business OR private, door locks OR file encryption, ... • PBE: Passphrase Based Encryption • For avoiding the hen-egg problem when encrypting keys • Long (>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 channels • Known to be secure / no eavesdropping • Examples: 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 used • ONLY possibility for Vernam cipher

Key distribution:Certificate Authorities (1) • Central authority vouches for the association of a public key to an individual • Depends 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

Certificates Root-CA CA 1 ... CA n User 1 ... User n Message Program Key distribution:Certificate Authorities (2) • In theory, the hierarchy can be very deep, but in practice, it’s rather shallow: • CA=Certification Authority

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 C • Based on transitivity of trust • Problem, 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 time • Today’s secure keys can be broken/forged easily in several years • Some 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 needed • Every 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 document • Unchangeability: The document cannot be changed anymore after the signature was created • Association with person: The signature is associated with exactly one singular person • Verifiability: Anybody can verify whether the signer is the person he/she claims to be • Unforgeable: Can only be created by a single person. The signer cannot deny having signed it

Functions of signatures What a signature should provide • Conclusion: 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, secure • Unique 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 control • Linked 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 these • 10 requirements for the certificate itself • Issued by an CA for qualified certificates • 12 requirements + lots of rules • Allows limitations of scope or value of transactions • Pseudonym instead of name possible • Must 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 revoked • Private key lost, chipcard stolen, password disclosed, ... • Technical problems • No generally agreed upon standard; different solutions • No offline check for revocation possible • Legal regulations (Austria): • EU: CA must provide “secure & immediate revocation service” • Must also be possible in (hand-)written form • At most after 3 hours completed • Two 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, except • All real estate contracts excluding rental rights • All 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 profession • Contracts of family law or the law of succession

EU Signature directive: Liability • CA is liable to ANYONE who reasonably relied on a qualified certificate, for • all information in the certificate at the time of issuing, • that it is a valid qualified certificate, • the signator held the private key • private 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’s • Austria: 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-Austria • Technical part: Inspection of CA’s for RTR • Association: University Graz, Ministry of Finance, Austrian National Bank • Currently 5 CA’s; 2 offering advanced signatures • Few certificates in use • Lack of applications • Only very recently advanced signatures available

US El. Signatures Act(1) • Much broader than EU directive, much less technical • Electronic 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 both • No invalidity solely because of electronic form!

US El. Signatures Act(2) • Exemptions: • Creation/Execution of wills, codicils or testamentary trusts • Adoption, divorce or other matters of family law • All commercial transactions except sales, leases, waivers of renunciation • Court documents (orders, notices, pleadings, …) • Cancellation or termination of utility services, health insurance or life insurance • Certain notices regarding primary residences of individuals (repossession, eviction, ...) • Accompanying documents for hazardous goods

US El. Signatures Act(3) • 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