Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 29904: Identity-Based Encryption — Algorithms, Protocols, and Implementation
A comprehensive technical guide to ISO 29904 standards for IBE algorithms, including Boneh-Franklin, Sakai-Kasahara, hybrid encryption, and practical deployment guidance.
Introduction to ISO 29904: Identity-Based Encryption — Algorithms and Protocols
ISO 29904 builds upon the mathematical infrastructure defined in ISO 29903-1 to specify concrete, implementable algorithms for identity-based encryption systems. While Part 1 establishes the theoretical foundations of bilinear pairings and algebraic structures, Part 2 defines the specific cryptographic protocols, encoding schemes, and message formats that enable interoperable IBE implementations. This standard is essential reading for cryptographic engineers, security architects, and software developers building IBE-enabled applications.
The standard specifies four primary IBE schemes: the Basic Boneh-Franklin (BF) scheme for chosen-plaintext security, the Full Boneh-Franklin scheme for chosen-ciphertext security (IND-ID-CCA), the Sakai-Kasahara (SK) scheme based on a different mathematical construction, and the Boneh-Boyen (BB) scheme that offers security without random oracles. Each scheme is specified with complete algorithmic details, including system parameter generation, key extraction, encryption, and decryption procedures. The standard also defines hybrid encryption variants that combine IBE with symmetric-key cryptography for efficient encryption of arbitrary-length messages.
For most practical applications, the Full Boneh-Franklin scheme (BF-IBE) in hybrid encryption mode is the recommended choice. It provides the strongest security guarantees (IND-ID-CCA) while maintaining reasonable computational efficiency. The Sakai-Kasahara scheme offers faster encryption but requires careful implementation to avoid padding oracle vulnerabilities.
Boneh-Franklin IBE: The Foundational Scheme
The Boneh-Franklin IBE scheme, first published in 2001, remains the most widely deployed and extensively analyzed IBE construction. ISO 29904 specifies both the BasicIdent and FullIdent variants. BasicIdent provides semantic security against chosen-plaintext attacks (IND-ID-CPA) using a single hash function H1 mapping identities to group elements and a second hash function H2 for message encoding. The encryption process takes an identity string ID and a message M, computes gID = e(H1(ID), Ppub) where Ppub is the public master key, and produces a ciphertext C = (U, V) where U = rP and V = M XOR H2(gID^r).
The FullIdent variant extends BasicIdent to provide security against adaptive chosen-ciphertext attacks through the Fujisaki-Okamoto transformation. This transformation adds a verification step that detects tampering with ciphertexts, preventing attackers from extracting information through decryption queries. The standard specifies precise byte-level encoding formats for all ciphertext components, ensuring interoperability between different implementations. Key sizes are defined for multiple security levels, with the 128-bit security level using a 256-bit BN curve producing ciphertexts of approximately 70 bytes plus the symmetric-encrypted message payload.
| Scheme | Security Level | Security Model | Ciphertext Overhead | Decryption Cost (relative) |
|---|---|---|---|---|
| BasicIdent | IND-ID-CPA | Random oracle | ~64 bytes | 1 pairing + 1 exponentiation |
| FullIdent (BF) | IND-ID-CCA | Random oracle | ~70 bytes | 1 pairing + 2 exponentiations |
| Sakai-Kasahara | IND-ID-CCA | Random oracle | ~60 bytes | 1 exponentiation (no pairing) |
| Boneh-Boyen | IND-ID-CCA | Standard model | ~100 bytes | 3 pairings + 2 exponentiations |
The BasicIdent scheme should never be used in production systems. It is vulnerable to chosen-ciphertext attacks where an attacker can decrypt arbitrary ciphertexts by making decryption queries. Always use the FullIdent variant or apply the Fujisaki-Okamoto transformation for any deployment handling sensitive data.
Encoding, Serialization, and Key Formats
ISO 29904 specifies detailed encoding and serialization formats for all IBE cryptographic objects, including system parameters, public keys, private keys, and ciphertexts. The standard uses Distinguished Encoding Rules (DER) for parameter serialization, providing compatibility with existing cryptographic infrastructure. System parameters are encoded as a SEQUENCE containing the curve identifier, generator point, public master key point, and hash function identifiers. Private keys are encoded as ASN.1 structures with access control metadata that specifies which identities the key is authorized to decrypt for.
The standard also defines a comprehensive key derivation framework for IBE, enabling the derivation of encryption keys for hierarchical identities. The hierarchical IBE (HIBE) extension allows parent identities to generate private keys for child identities, supporting organizational structures such as “admin@example.com” deriving keys for “user@example.com”. ISO 29904 specifies the encoding for hierarchical identity strings using forward-slash delimiters and defines the key derivation protocol that enables delegation without exposing the parent’s master secret.
Hierarchical IBE (HIBE) is one of the most powerful features of ISO 29904, enabling efficient key management for large organizations. With HIBE, a department-level PKG can generate keys for its members without accessing the organization-wide master secret, significantly reducing the risk of master key compromise. The standard supports up to 8 hierarchy levels for practical deployments.
Practical Deployments and Implementation Guidance
ISO 29904 provides comprehensive implementation guidance covering performance optimization, side-channel resistance, and integration with existing security infrastructure. For performance-critical applications, the standard recommends precomputation techniques for pairing values, batch processing for multiple simultaneous decryption operations, and hardware acceleration using trusted execution environments such as Intel SGX or ARM TrustZone. The standard also specifies countermeasures against timing attacks, power analysis attacks, and fault injection attacks, which are essential for implementations running in adversarial environments such as mobile devices and cloud servers.
The standard dedicates significant attention to interoperability testing and certification. ISO 29904 defines a set of test vectors for each scheme variant, enabling developers to verify the correctness of their implementations. These test vectors cover all phases of the IBE protocol: system parameter generation, key extraction, encryption, and decryption. The standard also specifies a protocol for IBE-enabled secure email, including message format specifications, key exchange protocols, and integration with S/MIME and OpenPGP message formats. For IoT applications, the standard defines lightweight IBE variants that reduce computational and communication overhead for resource-constrained devices.
Implementing cryptographic algorithms requires extreme attention to detail. Side-channel vulnerabilities have been found in many IBE implementations due to subtle issues in pairing computation, exponentiation timing, and memory access patterns. Always use constant-time implementations for all cryptographic operations, and consider using formally verified cryptographic libraries when available.
Frequently Asked Questions
Q: How does key revocation work in IBE systems under ISO 29904?
A: ISO 29904 specifies several approaches to key revocation. The most practical approach uses time-bound identities (e.g., “user@example.com||2026-06-01”), where the PKG issues private keys that are only valid until a specified expiration date. For immediate revocation, the standard supports blacklist-based revocation and mediator-based revocation where a semi-trusted mediator assists with decryption.
Q: What are the patent considerations for deploying IBE technology?
A: The fundamental Boneh-Franklin IBE patent (US Patent 7,113,594) has expired, making the basic IBE schemes freely available for commercial use. However, certain extensions and optimizations may still be covered by active patents. Organizations should conduct their own patent landscape analysis before deploying IBE in commercial products.
Q: Can ISO 29904 be used for encrypting communications between IoT devices?
A: Yes, the standard includes specific provisions for IoT deployments. The lightweight IBE variant reduces pairing computations through offline precomputation and uses smaller curve parameters optimized for constrained devices. An IBE encryption operation on a typical ARM Cortex-M4 processor takes approximately 30-50 milliseconds, making it suitable for many IoT applications.
Q: How does ISO 29904 handle identity string normalization and canonicalization?
A: The standard specifies that identity strings must be normalized using the Unicode Normalization Form C (NFC) before any cryptographic operations. For email addresses, the local part is case-sensitive while the domain part is lowercased. These normalization rules ensure that the same logical identity always produces the same cryptographic keys.
