Integrity

ISO/IEC 27000 defines integrity simply as the property of accuracy and completeness, while the US FISMA definition used in FIPS 199 speaks of guarding against improper modification or destruction and explicitly folds in authenticity and non-repudiation. In practice the term covers two different problems: detecting unauthorised or accidental change to data, and ensuring that authorised changes are themselves correct, which is a matter of business rules, validation and process rather than cryptography.

The cryptographic toolkit forms a ladder. A checksum or CRC detects random corruption but offers no protection against a deliberate attacker, who can simply recompute it. A cryptographic hash such as SHA-256 is collision-resistant, but a bare hash only helps if the reference value itself is delivered over a trusted channel. A message authentication code such as HMAC (RFC 2104) binds integrity to a shared secret key, so anyone holding the key can verify and also forge; it therefore gives integrity and data-origin authentication between two parties but not non-repudiation. A digital signature uses an asymmetric key pair, so only the private-key holder can sign and anyone can verify, which is what makes non-repudiation possible. Modern protocols use authenticated encryption (AEAD), for example AES-GCM or ChaCha20-Poly1305 in TLS 1.3, so that confidentiality and integrity are provided together and tampered ciphertext is rejected before decryption output is used.

At the model level, the Biba model (1977) is the integrity counterpart of Bell-LaPadula, forbidding subjects from reading down to less trustworthy data or writing up to more trustworthy data, and the Clark-Wilson model (1987) describes commercial integrity through well-formed transactions, constrained data items and separation of duties. Databases enforce integrity through constraints, transactions and ACID properties; storage uses checksumming file systems and Merkle trees; backups use immutable or WORM storage so ransomware cannot rewrite them; software supply chains rely on code signing, reproducible builds and provenance frameworks such as SLSA.

Common failure modes include verifying a hash downloaded from the same compromised server as the file, signing data but never checking the signature, and logs that an administrator can edit, which undermines both forensic value and accountability. Business email compromise shows that integrity attacks often target process, not bits: a correctly transmitted invoice with a changed account number passes every technical check. GDPR Art. 5(1)(f) and Art. 32(1)(b) name integrity explicitly, and an unauthorised alteration of personal data counts as a personal data breach under Art. 4(12).