E-Signatures: Aadhaar e-Sign, eIDAS and ESIGN / UETA

Public Key Infrastructure (PKI) is the cryptographic architecture that makes digitally verifiable electronic signatures possible. The core concept is asymmetric cryptography: each participant in the system holds a key pair consisting of a private key (kept secret, used to sign) and a public key (distributed widely, used to verify). A signature is created by computing a cryptographic hash of the document being signed (SHA-256 or SHA-384 in current best practice; SHA-1 is deprecated for new signatures across all major frameworks) and encrypting that hash with the signer's private key. The resulting ciphertext is the signature. Any recipient who holds the signer's public key can decrypt the ciphertext, compare the decrypted hash with a freshly computed hash of the received document, and verify that the document has not been altered since signing.

The problem PKI solves is not the cryptographic operation but the identity binding: how does the verifier know that the public key they hold actually belongs to the claimed signer, rather than to an attacker who has substituted their own key? The answer is the X.509 digital certificate: a data structure that binds a public key to a named identity (the subject) and is itself signed by a Certificate Authority (CA). The CA's own certificate is either self-signed (a root CA) or signed by a higher CA (an intermediate CA). The resulting chain from the signer's certificate up through intermediate CAs to a root CA is the certificate chain. A verifier who trusts the root CA (because it is pre-installed in their operating system's trust store, or is on a government-mandated trusted list) can verify every link in the chain.

Hash algorithm choice matters forensically. SHA-1 collision attacks were practically demonstrated in 2017 (the SHAttered attack, CWI Amsterdam and Google Research). Documents signed with SHA-1 certificates before 2016 were issued in a context where SHA-1 was still widely considered acceptable, but signatures on documents claimed to be from before 2010 that use SHA-256 may be anachronistic if the claimed authoring application did not support SHA-256 at that date. NIST deprecated SHA-1 for generating new digital signatures in SP 800-131A (2011), disallowing it after 2013; FIPS 186-4 (2013) continued to list SHA-1 as a permitted hash function. The CA/Browser Forum required all publicly trusted CAs to stop issuing SHA-1 certificates after January 2016. The examiner should verify that the hash algorithm used in each certificate in the chain is consistent with the claimed issuance date.

Revocation is the mechanism by which a CA declares that a certificate is no longer valid before its scheduled expiry date (typically because the private key was compromised, or the certificate was issued incorrectly). Two revocation mechanisms exist. The Certificate Revocation List (CRL) is a signed list of revoked certificate serial numbers published by the CA at a URL embedded in the certificate's CRL Distribution Points extension; verifiers download the CRL and check whether the certificate's serial number appears. The Online Certificate Status Protocol (OCSP) is a real-time query protocol in which the verifier sends the certificate's serial number to the CA's OCSP responder and receives a signed "good", "revoked", or "unknown" response. In PDF signature contexts, OCSP stapling embeds the OCSP response alongside the signature at signing time, preserving the revocation status as of the signing date even if the OCSP responder is later taken offline.

India's foundational electronic signature legislation is the Information Technology Act 2000, which established the concept of the digital signature (section 3, using asymmetric cryptography and a hash function) and the electronic signature (section 3A, introduced by the IT Amendment Act 2008, which broadened the definition to include any technique that is reliable and appropriate for the purpose). The Controller of Certifying Authorities (CCA), operating under the Ministry of Electronics and Information Technology (MeitY), is the root trust anchor for India's PKI hierarchy and maintains the National Repository of Digital Certificates (NRDC).

Aadhaar e-Sign is a specific electronic signature service authorised under the UIDAI (Unique Identification Authority of India) framework and the Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2015. The workflow is as follows: the user is authenticated by their Aadhaar number and either a biometric (fingerprint or iris scan) or an OTP (one-time password sent to the Aadhaar-registered mobile number); upon successful authentication, UIDAI's Aadhaar Signing Service (ASP and ESP, Application Service Provider and e-Sign Service Provider) generates a temporary signing key pair on behalf of the user, obtains a short-validity certificate (typically valid for 30 minutes) from a licensed Certifying Authority, signs the document with the temporary private key, and immediately discards the private key. The resulting signature is backed by a CA certificate whose subject identity is drawn directly from the UIDAI's Aadhaar database.

The forensic significance of this architecture is substantial. First, the signature certificate's subject name and Aadhaar identity are bound at the time of each signature event, not at a one-time certificate issuance; the signer cannot deny awareness of the specific signing event. Second, the UIDAI logs each signing transaction (date, time, document hash, Aadhaar number) with a retention period sufficient for evidentiary access under court order. Third, the short certificate validity means that an Aadhaar e-Sign certificate presented for verification will always show as expired when verified without a trust anchor configured to accept historical OCSP staples or long-term validation (LTV) data embedded at signing time. The examiner must understand LTV validation and the role of archived OCSP responses to correctly verify older Aadhaar e-Sign documents.

In the Bharatiya Sakshya Adhiniyam (BSA) 2023 (which replaced the Indian Evidence Act 1872), electronic records and electronic signatures are addressed in sections 57 to 59. Section 63 of the BSA provides for the admissibility of electronic records in evidence subject to an electronic record certificate (the former section 65B certificate under the Indian Evidence Act). Courts have interpreted the Supreme Court's ruling in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (2020) as requiring the person producing the certificate to be able to speak to the electronic record's integrity, which the Aadhaar e-Sign log and the LTV-embedded OCSP response together support.

EU Regulation 910/2014 (eIDAS) establishes three tiers of electronic signature, each with distinct technical requirements and legal effects. The Simple Electronic Signature (SES) is any data in electronic form that is attached to or logically associated with other data, and that the signatory uses to sign. A scanned handwritten signature, a typed name, a click-wrap agreement checkbox: all qualify as SES. SES carries no cryptographic assurance; its legal weight depends entirely on context and the broader evidentiary record.

The Advanced Electronic Signature (AdES) must meet four requirements under eIDAS Article 26: it is uniquely linked to the signatory; it is capable of identifying the signatory; it is created using electronic signature creation data (the private key) that the signatory can use with a high level of confidence under their sole control; and it is linked to the signed data in such a way that any subsequent change in the data is detectable. In practice, an AdES is implemented via a PKI signature with an appropriate certificate, but the certificate does not need to be a qualified certificate from the Trusted List. Most commercial electronic signature platforms (DocuSign, Adobe Sign, Skribble, SignNow) issue signatures at the AdES level in EU deployments.

The Qualified Electronic Signature (QES) carries the highest technical bar and the most significant legal effect. Under eIDAS Article 25(2), a QES has the equivalent legal effect of a handwritten signature across all EU member states. A QES must: be created by a Qualified Signature Creation Device (QSCD); be backed by a qualified certificate issued by a Trust Service Provider (TSP) on the EU Trusted List; and include a timestamp from a qualified timestamping authority on the Trusted List. A QSCD is a hardware or software device (most commonly a hardware security module, a USB token such as SafeNet eToken, or a remote HSM operated by the TSP) that stores the private key such that it cannot be extracted, ensuring that the key is under the sole control of the signatory.

The EU Trusted List (the EUTL, maintained by the European Commission at the esignature.europa.eu portal) lists all TSPs per member state that are permitted to issue qualified certificates or provide qualified timestamping. An examiner verifying a claimed QES must confirm that the issuing CA appears on the EUTL as a qualified TSP for the relevant service type at the claimed signing date: TSPs can be added to or removed from the list, and a certificate issued by a TSP after its removal from the list does not carry QES status.

The Electronic Signatures in Global and National Commerce Act (ESIGN Act, 15 U.S.C. § 7001 et seq.) was enacted in 2000 and established a federal baseline: no electronic signature may be denied legal effect solely because it is in electronic form. The Uniform Electronic Transactions Act (UETA), adopted in its model form by 49 US states and the District of Columbia (New York uses its own Electronic Signatures and Records Act, ESRA), provides the state-level parallel: an electronic record or electronic signature satisfies a requirement for a signature under applicable state law.

Neither ESIGN nor UETA mandates any specific technology. A handwritten signature on a tablet, a biometric voice signature, an asymmetric-key digital signature, a shared-secret OTP confirmation: all can constitute valid electronic signatures under ESIGN/UETA, provided the parties have agreed to transact electronically and the signer has demonstrated intent to sign. This technology-neutral approach differs substantially from eIDAS, which creates distinct legal tiers by technology type. The forensic consequence is that a US examiner investigating a contested electronic signature must evaluate: the evidence of the signatory's intent (click-to-agree logs, audit trails, email chains); the integrity of the document from the time of signing (hash logs, audit trail hashes); and the reliability of the electronic signature system's own record-keeping.

Commercial electronic signature platforms operating in the US market (DocuSign, Adobe Acrobat Sign, HelloSign, PandaDoc) maintain detailed audit trails including: the signatory's IP address, geolocation, device fingerprint (user-agent string), email address used for notification, timestamp of each signing event, and a hash of the signed document at the time of signing. These audit trails are themselves electronic records subject to the same evidence admissibility rules and are a primary forensic resource in contested-signature litigation. In federal court, ESIGN audit trail evidence is typically introduced under Federal Rule of Evidence 803(6) (records of a regularly conducted activity) through a qualified witness from the platform provider.

Courts have generally accepted electronic signature audit trails as reliable. In Nortek Controls Corp. v. Acuity Brands Inc. (US District Court, N.D. Cal., 2019), the court accepted a DocuSign audit trail as establishing that the signatory had electronically signed the document at the claimed time. In Phison Electronics Corp. v. Kingston Technology Co. (C.D. Cal., 2017), the court examined the authenticity of an electronically signed NDA. In the UK, the Law Commission's 2019 report "Electronic Execution of Documents" confirmed that ESIGN-equivalent simple electronic signatures satisfy UK law requirements in most commercial contexts under the Electronic Communications Act 2000, provided the parties intended to be bound.

The Electronic Communications Act 2000 (ECA 2000) is the primary UK legislation governing electronic signatures. Section 7 provides that electronic signatures are admissible in evidence in relation to any question as to the authenticity or integrity of a communication or data, and section 7(2) defines an electronic signature as anything in electronic form that is incorporated or logically associated with the electronic communication and purports to be used to authenticate the communication. This definition is functionally equivalent to eIDAS SES and ESIGN Act definitions: broad, technology-neutral, and focused on intent to authenticate rather than technical method.

Following the UK's departure from the EU, the eIDAS Regulation was retained in UK domestic law as "UK eIDAS" by the European Union (Withdrawal) Act 2018, but mutual recognition of EU qualified signatures and EU Trusted List TSPs no longer operates automatically. A qualified electronic signature issued by an EU TSP on the EU Trusted List is not automatically recognised as a QES for UK legal purposes post-Brexit; the UK's own Conformity Assessment Bodies and TSP framework (operated under the DCMS and the National Cyber Security Centre, NCSC) apply independently. The Law Commission's 2019 report and subsequent consultations have confirmed that the UK does not intend to legislate a tiered QES regime equivalent to eIDAS; the broad ECA 2000 approach continues to apply.

For forensic examiners handling documents that have crossed between EU and UK jurisdictions, the key practical implication is that a QES under EU eIDAS may need to be presented to a UK court via expert evidence establishing its technical validity, rather than relying on automatic statutory equivalence. Similarly, a UK electronic signature does not automatically carry QES status in an EU member state court. In practice, most high-value cross-border contracts use platforms certified under both the EU Trusted List and the UK CAB framework, or fall back to wet-ink signatures for documents where QES equivalence is legally material.

The examiner workflow for a contested electronically signed document proceeds through four layers that must be addressed in sequence, because failures at a lower layer affect the interpretation of findings at higher layers.

The first layer is document integrity: has the document been altered since it was signed? For cryptographically signed documents (PDF with PKCS#7 signature, XML with XMLDSig, CMS-signed email), the hash verification at this layer is deterministic: re-compute the hash over the ByteRange or the canonicalised XML, compare with the decrypted signature value. For non-cryptographically signed documents (ESIGN audit trail-based signatures), this layer requires obtaining the platform's tamper-evident audit log and the hash of the document as recorded at signing time.

The second layer is certificate chain verification: is the signer's certificate validly issued by a CA that the applicable jurisdiction trusts? This requires traversing the full certificate chain (end-entity, intermediates, root) and verifying that each certificate was signed by its issuer, that no certificate was expired at the time of signing, and that the root CA is on the appropriate trust list (Windows root store, Mozilla NSS, Apple Trust Store, the EU Trusted List, India's NTR operated by the CCA, or a jurisdiction-specific equivalent).

The third layer is revocation status at signing time: was the certificate revoked before the document was signed? For OCSP, this requires either a stapled OCSP response embedded in the signature (verifiable without network access) or access to archived OCSP responses from the CA or a trusted OCSP archiver. For CRL-based systems, the relevant CRL as of the signing date must be retrieved. In long-term archival contexts (documents signed years before the examination), the examiner must rely on LTV (Long-Term Validation) data embedded at signing time under the PAdES-LTV profile (ETSI EN 319 102-1) or equivalent.

The fourth layer is timestamp authenticity: does the embedded timestamp from the TSA accurately record the signing time? The TSA timestamp is itself a cryptographic structure: the TSA signs a hash of the signature value and a time value using its own certificate, which must also be verified against a trusted root. The TSA timestamp is the primary evidence for the signing time and takes precedence over the document's EXIF creation date, the PDF information dictionary's ModDate field, and any other metadata that is not cryptographically protected.

1. Establish jurisdiction and claimed tier
   Identify from context (contract terms, issuing institution, document type) which signature framework governs the document and what tier the signature claims (SES, AdES, QES under eIDAS; digital signature under IT Act 2000; ESIGN audit-trail signature in the US; ECA 2000 signature in the UK). This determines what the examiner must verify to assess whether the claimed tier is achieved.
2. Extract the signature structure
   For PDF: use a PDF forensic tool to locate the signature dictionary, extract the ByteRange, the PKCS#7 container, and any embedded LTV data or OCSP staples. For XML: locate the xmldsig:Signature element and the Reference elements with their digest values. For email: extract the S/MIME signature from the MIME envelope.
3. Verify document integrity hash
   Recompute the hash over the signed byte range or canonicalised content using the algorithm specified in the signature (SHA-256, SHA-384, etc.). Compare with the decrypted hash value from the signature. A mismatch proves post-signing modification. A match proves the signed content has not been altered.
4. Verify the certificate chain
   Extract all certificates from the signature container. Build the chain from end-entity to root. Verify each certificate's signature using its issuer's public key. Check that no certificate was expired at the time of signing. Confirm the root CA against the appropriate trust list for the claimed jurisdiction and signature tier.
5. Verify revocation status at signing time
   If LTV data or an OCSP staple is embedded, verify the OCSP response's signature and confirm the certificate's status was 'good' at the time of signing. If not embedded, retrieve the archived OCSP response or the relevant CRL from the CA's archive or a trusted OCSP archiver service.
6. Verify the TSA timestamp
   Verify the TSA's own certificate chain and confirm the timestamp token's cryptographic integrity. Record the timestamp value as the authoritative signing time. Compare against the document's other date indicators (PDF ModDate, EXIF, audit log) and note any discrepancies.
7. Document and report
   For each layer, record the result (pass, fail, or unable to determine with reason). If any layer fails, specify the failure mode and its forensic significance for the contested claim. Do not conflate a certificate expiry (a layer-2 finding) with a document tampering event (a layer-1 finding).