Chapter 19 — Identity and cryptography | Engineering Digital forensics and malware analysis

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 19 — Identity and cryptography

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Hash functions"]
  N2["19.2 Symmetric and public-key"]
  N3["19.3 Signatures for forensic records"]
  N4["19.4 Encryption in evidence"]
  N5["19.5 Identity and attribution"]
  N6["19.6 Key management"]
  N7["19.7 Certificates"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Hash functions"]
  N2["19.2 Symmetric and public-key"]
  N3["19.3 Signatures for forensic records"]
  N4["19.4 Encryption in evidence"]
  N5["19.5 Identity and attribution"]
  N6["19.6 Key management"]
  N7["19.7 Certificates"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Hash functions]
    |
    v
[19.2 Symmetric and public-key]
    |
    v
[19.3 Signatures for forensic records]
    |
    v
[19.4 Encryption in evidence]
    |
    v
[19.5 Identity and attribution]
    |
    v
[19.6 Key management]
    |
    v
[19.7 Certificates]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) explain hashing, symmetric and public-key cryptography; (2) apply digital signatures to forensic records; (3) explain what encryption means for examinations; (4) relate identity systems to attribution.

19.1 Hash functions

A cryptographic hash maps data to a fixed-length digest; it should be infeasible to find two inputs with the same digest. SHA-256 is the common forensic choice; MD5 and SHA-1 have known collision attacks, so labs that still record them do so alongside a stronger hash.

Recording both MD5 and SHA-256 lets the lab compare with older hash sets and reports while still relying on a strong algorithm. If the two digests ever disagree about whether two files match, the SHA-256 result decides. Priya's tools always print the algorithm name beside each value and never truncate digests in reports, because a shortened hash is much easier to match by accident.

19.2 Symmetric and public-key

Symmetric encryption uses one shared key. Public-key cryptography uses a key pair: what one key encrypts or signs, the other decrypts or verifies.

Symmetric ciphers are fast and suit bulk encryption, such as protecting evidence at rest, but both parties need the same key, which creates a distribution problem. Public-key systems solve distribution, because the public half can be shared openly. In practice, systems combine them: a public-key exchange sets up a symmetric key, which then encrypts the data. Examiners meet both kinds in encrypted containers and communications.

19.3 Signatures for forensic records

An examiner can sign a report or hash manifest with a private key; anyone with the public key can confirm it was not altered and came from that key holder. Trusted timestamps add evidence of when.

A signed hash manifest lets a court check that the list of evidence hashes has not changed since the examiner signed it, even if the manifest has passed through many hands. A trusted timestamp from an independent service adds evidence that the signature existed at a given time. Priya's EvidenceDesk design signs each day's custody log, so later edits would be detectable.

19.4 Encryption in evidence

Full-disk encryption means an image is unreadable without keys. Lawful key recovery depends on legal powers and what the owner or organisation provides, such as escrowed recovery keys. Examiners record encryption state and how access was lawfully obtained; they do not attempt to defeat protections without authority.

Encryption state can change during handling. A laptop seized while running may have its volume unlocked, and powering it off locks it again. Recording the state at seizure, and any keys or recovery information lawfully provided, is part of the acquisition record. An image of an encrypted volume is still preserved and hashed, because keys may become available later under proper authority.

19.5 Identity and attribution

Account logons show credentials were used, not who typed them. Multi-factor logs add context but still identify factors, not people.

A logon with a correct password and an approved push notification shows that the password was known and the registered phone approved the request. It does not show who held the phone. Attribution builds from several kinds of evidence, such as device location, other activity at the same time and witness accounts. Priya's report wording follows the evidence: 'the account authenticated', never 'the suspect logged in'.

19.6 Key management

Lab signing keys are protected, rotated and their use logged.

A lab signing key might sit on a hardware token that never exports the private key, with a PIN known only to authorised staff. Rotation means issuing a new key at set intervals and publishing the old public key with its validity period, so old signatures can still be checked. A compromised key is revoked at once, and signatures made after the compromise are re-examined. Every signing operation is logged with the operator and the document hash.

19.7 Certificates

Certificates bind public keys to names via a trusted issuer; validity periods and revocation must be checked.

When verifying a signed report years later, the question is whether the certificate was valid at the time of signing, not today. That needs a record of the signing time, ideally from a trusted timestamp, and revocation information from that period. Priya's design archives the certificate chain and revocation status with each signed artefact, because those online services may not exist in ten years.

Hash agility

Algorithms age. Priya designs EvidenceDesk so the algorithm is stored with every digest and new ones can be added without rewriting history.

Worked example

A signed manifest for case 41 fails verification. Priya checks: the manifest was edited to fix a typo after signing. The original signed version is restored and the correction is issued as a new, separately signed addendum.

Synthetic case. Case 41 is invented.

Errors and limits

A valid signature proves possession of the key, not the honesty of the signer.

Exercises

EX055 — MD5 caution. Why record SHA-256 alongside MD5? Rubric: 3 = MD5 collisions known; SHA-256 stronger; 2 = partial; 1 = habit; 0 = none.
EX056 — Failed signature. How was the case 41 failure resolved? Rubric: 3 = restore signed original; correction as signed addendum; 2 = partial; 1 = re-sign edited; 0 = none.
EX057 — Logon attribution. What does a successful logon show? Rubric: 3 = credentials used, not who; 2 = partial; 1 = identifies person; 0 = none.

Synthesis

Hashes and signatures protect forensic records; encryption and identity data need careful, lawful interpretation.

Continue studying — chapter 19 of 50

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →