Cryptography: Electronic Signatures

E-signed document

--A document with a(n advanced) electronic signature is authentic --where authenticity is provided by its encoding --this are all copies of the signed document also "original"

Signature policy

--A signature's validity is not objective--it depends on the policy we use for signature validation --The signature policy may include roots, algorithms, timings, timestamps, revocation information, grace periods, etc. --A signature's validity can be discussed in context of a policy only

Why timestamp?

--A signed document's lifetime may significantly exceed that of the certificate --Signatures must remain valid even if the signatory's certificate expires of is revoked --in order to verify a signature, we need a secure point in time when we can be sure the signature already existed --Time stamps provide this source of time --signature verification is usually based on time stamps

How long does a signature remain authentic?

--From a legal point of view, the validity of the signature does not fade away with time --From a technical point of view, it may become difficult to prove that a signature had been valid at a previous point of time --signature without timestamp?--> as long as the signer's cert is valid --signature with timestamp?--> as long as the TSA's cert is valid --if you want longer, the signature needs to be archived--it needs to be timestamped at regular intervals

Time stamping: general idea

--Requester sends to TSA (Time Stamping Authority) request to timestamp hash --TSA certifies that hash existed at a particular time --Online question, online answer with a secure time --TSA is required to maintain a secure clock Time stamping as a trust service --provides a secure time --links the secure time to a document --has a probative force --has a standard format

Qualified vs. Non-qualified signature

--The difference is primarily legal--the cryptographic technology behind them is the same --Differences: probative force, cross-border acceptance, service provider's liability, requirements on key management Qualified signature: --is it more secure? not necessarily --qualified means it is equivalent with a handwritten signature --it is "more straightforward" to accept qualified signatures EU legal systems define certain PKI-based (qualified) signatures as equivalent with handwritten ones; US legal systems do not emphasize PKI, but rather emphasize the circumstances

Electronic signature vs. Digital signature

--electronic signature = legal term (used for electronic authentication recognized by law --digital signature = technical term (used for encoding with one's private key) --not all electronic signatures are digital signatures (ex: writing one's name at the end of an email message) --not all digital signatures are electronic signatures (ex: usage of private key in case of a TLS authentication) --electronic signatures are not necessarily based on PKI and digital certificates--but the most "advanced" ones are

What is an electronic signature?

--electronic signature means "authenticating" an electronic document in an electronic way --so that it can be "proven" who signed it and what had been signed --electronic signatures are recognized by law --certain forms of electronic signatures can be considered equivalent with handwritten signatures (depending on legislation; examples: encoding or adding info about the signatory) --this allows e.g. contracts/declarations to be made in a purely electronic format, without the use of paper (if Alice signs a document, she signs with her private key and anyone can verify it with Alice's public key in her certificate)

Signature creation

1. the signatory reviews a document and decides to sign it 2. the signatory gives the document to a Signature Creation Application 3. the Signature Creation Application computes a hash of the document and sends the hash to a (Secure) Signature Creation Device 4. The Signature Creation Device computes the signature using the private key and sends it back to the Signature Creation Application, who appends it to the document --Signature block (signed part) includes hash of document, hash of certificate, further info (such as metadata, signature police etc.)--> .this is hashed and then that hash is signed and the signature is placed in the signature block --Signature container includes also the document itself, the certificate and unsigned information (certification path, timestamp, certificate revocation lists, OCSP responses), as well as the signature block itself

Qualified electronic signature

According to EU law, this is an electronic signature based on a qualified certificate, created with a secure signature creation device

Grace period

CRLs at the time of signing might mean unsuitable evidence because: --the user needs time to detect key compromise --the user needs time to report key compromise --the CA needs time to update its registry about the key compromise and publish the new revocation status --it takes time until new revocation status information propagates and all relying parties are notified --it may take time until someone can obtain *positive* confirmation of a signatures validity (up the whole certification chain...) Addressing grace period 1. Use the most recent revocation information (neglect grace period) 2. Apply grace period for end-entity certs, but do not apply for CA/TSA certs 3. Apply grace period at every level 4. Apply grace period at every level, use real-time revocation checking -> Via OCSP--to get immediate positive confirmation

Cryptographic verification (first part of verifying technical validity)

Hash the signature block and check the hash = signature on the block

Overall process for validating signature

Obtain "control time," i.e. the point of time we use for signature validation --if there is (one or more) time stamp, use that --if there is any other evidence, use that --worst case: use time of validation With respect to the "control time": --build a certification path --validate signature on all certs in the path-> recursion --collect evidence for revocation status of all certs in the path and validate the signature on all such evidence-> recursion --apply grace period as per signature policy

Formats

Signature format: describes how the signature was created, refers to policies, contains paths, CRLs, etc. Container format: helps you find what was signed, helps you when opening the signed doc, helps you manage multiple signatures --Format examples: ASN1-based formats (PKCS#7, for example), XML-based formats (XMLDSIG, for example) Signature examples: --PDF signature: document + signature container at once, contains PKCS#7 or CAdES signatures, supports visible signature --ES3 dossier: widely used in Hungary, XML container format, may contain multiple documents and multiple XAdES signatures over them, signatures can be timestamped and/or archived --OpenOffice signatures: ZIP file with a fixed structure, may contain multiple signatures, XMLDSIG signatures only, problems--no timestamps, compatibility issues

Signature verification

Verify technical validity: --cryptographic verification--does the required relation exist between the document, the public key and the signature --was the signatory's certificate valid at the time of signing Is the signature acceptable in the given legal and organizational context? --level of security of the signature --was the signer authorized to sign? --how sure am I in the validity of the signature? --signature policy? --did the signer mean to sign the document? --was it the signer (person) who signed the document?

Checking the signer's cert was valid at the time of signing (second part of verifying technical validity)

When was the signature created? --is there a timestamp? --do I have any other evidence? Can the signer's cert be chained to a trusted root? --with respect to the time of signing... --there can be multiple roots and/or multiple chains Were all certificates in the chain valid at the time of signing? --unexpired? --unrevoked?