Chapter 6

Security and Cryptographic Verification

Cryptographic techniques provide the mathematical foundation for document authenticity, integrity, and non-repudiation, ensuring public documents maintain the same legal validity as traditional paper documents with official seals.

Digital Signatures and PKI

Digital signatures are the electronic equivalent of handwritten signatures and official seals. Using public key cryptography, the signer's private key transforms document content into a signature value that can be verified using the corresponding public key. Unlike handwritten signatures which can be forged, properly implemented digital signatures provide strong mathematical guarantees: only the holder of the private key could have created the signature, the signed content has not been altered since signing, and the signer cannot later deny creating the signature (non-repudiation).

Signature Algorithm Selection

The WIA-SOCIAL standard supports multiple signature algorithms to accommodate different security requirements and computational constraints. RSA with SHA-256 or stronger provides widely compatible signatures suitable for most applications. ECDSA (Elliptic Curve Digital Signature Algorithm) with P-256, P-384, or P-521 curves offers equivalent security with shorter key lengths and faster operations. EdDSA with Ed25519 or Ed448 curves provides excellent performance and resistance to implementation mistakes.

Public Key Infrastructure (PKI)

PKI provides the trust framework linking public keys to identities. A Certificate Authority (CA) issues digital certificates binding public keys to entities (government agencies, officials, systems). The CA signs certificates with its private key, creating a chain of trust. Verifiers check certificate signatures up the chain to a root CA certificate they trust (pre-installed in operating systems or distributed by government).

Government PKI hierarchies typically have multiple tiers. Root CAs are kept offline in highly secure facilities, their private keys protected by Hardware Security Modules (HSMs) in geographically distributed secure vaults. Root CAs issue certificates to intermediate CAs which handle day-to-day certificate issuance. This isolates root key exposure—if an intermediate CA is compromised, only certificates it issued must be revoked; the root remains trusted. Multiple intermediate CAs serve different purposes: document signing, TLS server authentication, code signing, user authentication.

Root CA: Estonian Government Root CA
  ↓ [signed by Root CA]
Intermediate CA: Estonian Document Signing CA
  ↓ [signed by Intermediate CA]
End-Entity Certificate: Ministry of Interior Document Signer #47
  Subject: CN=MoI Doc Signer 47, O=Ministry of Interior, C=EE
  Public Key: [ECDSA P-384 public key]
  Key Usage: Digital Signature, Non-Repudiation
  Extended Key Usage: Document Signing
  Validity: 2024-01-01 to 2026-12-31

Verification Process:
1. Extract document signature and signing certificate
2. Verify document signature using certificate's public key
3. Verify certificate was signed by intermediate CA
4. Verify intermediate CA certificate was signed by root CA
5. Verify root CA certificate is in trusted root store
6. Check that no certificates in chain are revoked (OCSP/CRL)
7. Verify certificates haven't expired
→ If all checks pass: signature valid, document authentic

Hardware Security Modules (HSMs)

Private keys used for signing critical documents must be protected from compromise. Software key storage is vulnerable to theft through malware, operating system vulnerabilities, or insider threats. Hardware Security Modules provide tamper-resistant hardware that performs cryptographic operations without exposing private keys to software systems.

HSM Capabilities

HSMs generate keys within the device, ensuring keys never exist outside the protected boundary. They perform signing operations internally, accepting plaintext or hash values and returning signatures without exposing keys. Access controls enforce multi-party authorization for sensitive operations like key generation or export. Audit logs record all cryptographic operations. Physical tamper detection destroys keys if the device is opened or subjected to environmental attacks. FIPS 140-2 Level 3 or 4 certification provides assurance of security design and implementation.

Modern cloud HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) provide HSM capabilities without requiring physical hardware management. Keys remain in FIPS 140-2 Level 3 certified hardware controlled solely by the customer. These services integrate with key management systems and cryptographic libraries, simplifying HSM adoption while maintaining security properties.

Certificate Revocation

Sometimes certificates must be revoked before their expiration date—if private keys are compromised, if an official leaves their position, if certificate information becomes inaccurate, or if security vulnerabilities are discovered. Two mechanisms enable checking certificate revocation status: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP).

Certificate Revocation Lists (CRLs)

CAs periodically publish lists of revoked certificate serial numbers. Verifiers download and cache CRLs, checking whether certificates appear in the list. CRLs are simple and work offline (once downloaded) but have scalability challenges. Large CAs may have CRLs containing millions of entries, requiring megabytes of download. CRLs are only current as of publication time, introducing revocation latency.

Online Certificate Status Protocol (OCSP)

OCSP provides real-time revocation checking. Verifiers send certificate serial numbers to an OCSP responder, which returns revocation status. This provides up-to-date information without downloading large CRLs. OCSP responses are small (typically <1KB) and can be cached. However, OCSP introduces network dependency—verification fails if the OCSP responder is unavailable. OCSP stapling addresses this by having servers obtain OCSP responses and include them with TLS handshakes.

OCSP Request:
POST /ocsp HTTP/1.1
Host: ocsp.gov.ee
Content-Type: application/ocsp-request

[binary OCSP request containing certificate serial number]

OCSP Response:
HTTP/1.1 200 OK
Content-Type: application/ocsp-response

{
  "certificateSerial": "0x3A7F2E...",
  "status": "good",  // or "revoked" or "unknown"
  "thisUpdate": "2025-01-15T10:30:00Z",
  "nextUpdate": "2025-01-15T11:30:00Z",
  "revokedAt": null,
  "revokedReason": null
}

Status Values:
- "good": Certificate is valid and not revoked
- "revoked": Certificate has been revoked
- "unknown": Responder doesn't know about this certificate

Document Encryption

While digital signatures provide authenticity and integrity, encryption provides confidentiality. Sensitive documents must be encrypted both at rest (in storage) and in transit (during transmission). The WIA-SOCIAL standard supports multiple encryption approaches for different scenarios.

Symmetric Encryption

Symmetric algorithms like AES use the same key for encryption and decryption. AES-256-GCM (Galois/Counter Mode) provides both encryption and authentication, preventing both eavesdropping and tampering. Symmetric encryption is fast and suitable for bulk data. The challenge is key distribution—sender and receiver must securely share the key.

Asymmetric Encryption

Asymmetric algorithms use public keys for encryption and private keys for decryption. Anyone can encrypt data using a recipient's public key, but only the recipient with the corresponding private key can decrypt. RSA and ECIES (Elliptic Curve Integrated Encryption Scheme) provide asymmetric encryption. However, asymmetric encryption is slow and limited to small data sizes. Hybrid approaches encrypt data with a symmetric key, then encrypt the symmetric key with asymmetric encryption, combining benefits of both.

End-to-End Encryption

For maximum privacy, documents can be encrypted client-side before uploading to servers. Only the intended recipient's private key can decrypt. Even if servers are compromised, attackers cannot read document contents. This provides strong privacy but complicates features like search and content analysis. Attribute-Based Encryption and Homomorphic Encryption offer possibilities for processing encrypted data without decryption, though with significant complexity.

JSON Web Encryption (JWE) Compact Serialization:

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.
[encrypted symmetric key]
.
[initialization vector]
.
[encrypted content]
.
[authentication tag]

Structure:
1. Header (Base64URL encoded):
   {
     "alg": "RSA-OAEP-256",  // Key encryption algorithm
     "enc": "A256GCM"         // Content encryption algorithm
   }

2. Encrypted Key:
   - Generate random AES-256 key (Content Encryption Key - CEK)
   - Encrypt CEK using recipient's RSA public key
   - Result is encrypted symmetric key

3. Initialization Vector:
   - Random value for AES-GCM

4. Ciphertext:
   - Document content encrypted with CEK using AES-256-GCM

5. Authentication Tag:
   - GCM authentication tag proving integrity

Decryption Process:
1. Verify JWE structure and header
2. Decrypt CEK using recipient's RSA private key
3. Decrypt content using CEK and IV
4. Verify authentication tag
→ If all steps succeed: document decrypted and authentic

Privacy-Enhancing Technologies

Beyond basic encryption, advanced cryptographic techniques enable privacy-preserving document operations. These allow verification of document properties without revealing full contents, minimizing data exposure while maintaining functionality.

Selective Disclosure

Rather than sharing an entire document, citizens can selectively disclose specific attributes. A driver's license holder can prove they're over 21 without revealing their exact birth date or address. Implementation approaches include separate signatures on each attribute (allowing selective inclusion), zero-knowledge proofs (proving properties without revealing data), or credential revocation lists combined with attribute commitments.

Zero-Knowledge Proofs

Zero-knowledge proofs allow proving statements about data without revealing the data itself. For example, proving "I am over 18" without revealing your birth date, or proving "I have a valid driver's license" without revealing the license number or expiration date. zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) provide compact proofs that can be verified quickly. While computationally intensive to generate, verification is fast, making them suitable for privacy-preserving document applications.

Blind Signatures

Blind signatures allow authorities to sign documents without seeing their contents. The requester blinds (encrypts) the document, sends it for signing, receives the blind signature, then unblinds to obtain a standard signature. This enables issuing authorities to certify documents while preserving privacy. Applications include anonymous credentials and privacy-preserving authentication tokens.

GDPR and Data Protection Compliance

The European Union's General Data Protection Regulation (GDPR) imposes strict requirements on personal data processing. Document systems handling EU citizen data must implement technical and organizational measures ensuring compliance.

Core GDPR Principles

Lawfulness, fairness, and transparency require clear legal basis for processing and informing data subjects. Purpose limitation means data can only be used for stated purposes. Data minimization requires collecting only necessary data. Accuracy requires keeping data correct and current. Storage limitation requires deleting data when no longer needed. Integrity and confidentiality require security measures. Accountability requires demonstrating compliance.

GDPR Rights Implementation

Data subjects have rights that document systems must support. Right of access requires providing copies of all data held. Right to rectification requires correcting inaccurate data. Right to erasure ("right to be forgotten") requires deletion in some circumstances (though exceptions apply for legal obligations). Right to data portability requires providing data in structured, machine-readable formats. Right to object allows refusing certain processing types. Systems must provide workflows and APIs implementing these rights.

Security Auditing and Compliance

Public document systems require regular security audits and compliance assessments. Multiple frameworks provide standards and methodologies for evaluating security posture.

ISO 27001 Information Security Management

ISO 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). It covers risk assessment, security controls implementation, incident management, business continuity, and continuous improvement. Certification provides assurance to stakeholders that appropriate security measures are in place.

Common Criteria Certification

Common Criteria (ISO/IEC 15408) provides a framework for evaluating computer security products. Evaluation Assurance Levels (EALs) range from EAL1 (basic) to EAL7 (highest rigor). Government document systems typically target EAL4+ for critical components like cryptographic modules and authentication systems.

Penetration Testing

Regular penetration testing simulates real-world attacks to identify vulnerabilities. Tests should cover web application security (OWASP Top 10), API security, authentication bypass attempts, authorization flaws, cryptographic weaknesses, and infrastructure vulnerabilities. Both automated scanning and manual expert testing are necessary. Critical systems should undergo testing at least annually, with continuous automated scanning.

Summary

Review Questions

1. How do digital signatures provide non-repudiation? Why can't signers deny creating signatures?
2. Explain the PKI certificate chain. How does trust flow from root CAs to end-entity certificates?
3. What security properties do HSMs provide that software key storage doesn't? Why are they essential for government systems?
4. Compare CRLs and OCSP for certificate revocation checking. What are the trade-offs?
5. Explain hybrid encryption as used in JWE. Why combine symmetric and asymmetric encryption?
6. What are zero-knowledge proofs and how do they enable privacy-preserving verification? Give a practical example.
7. Describe three GDPR rights and how document systems must implement them. What technical challenges arise?
8. Why is penetration testing necessary even for systems that pass automated security scans?