The shape of the lesson
By the end of the lesson, learners can
- Getting a certificate: Anyone can generate a key pair and claim it belongs to a bank.
- Making a signature: Encrypting a whole document with a private key would be slow.
- What signatures prove: A digital signature on its own does not hide the message; it is often sent as plaintext.
- Certificate: applicant sends public key and identity to a CA; CA verifies identity and signs with the CA’s private key.
- Sign: hash the message to a digest; encrypt the digest with the sender’s private key.
- Verify: decrypt the signature with the sender’s public key (from the certificate); re-hash the message; compare.
- Provides: authentication, integrity, non-repudiation; not confidentiality.
One picture every idea returns to
A digital certificate is an electronic document, issued by a trusted certificate authority (CA), that links an owner’s identity to their public key. The CA signs it with the CA’s private key. To make a digital signature, the sender hashes the message to produce a message digest and encrypts the digest with the sender’s private key. The receiver decrypts the signature with the sender’s public key (taken from the certificate), hashes the received message with the same algorithm and compares the two digests. A match proves the message is authentic and unaltered.
Forty-five minutes, phase by phase
| Time | Phase | What happens in the room | Grouping |
|---|---|---|---|
| 0 to 5 min | Hook: predict | Open with the question in the title, Prove who sent it.. A public key is only useful if you can trust whose key it is. Put the figure on the board: it is the one picture every idea in the lesson returns to. | Whole class, then pairs |
| 5 to 13 min | Teach and check: Getting a certificate | Anyone can generate a key pair and claim it belongs to a bank. | Whole class, then pairs |
| 13 to 21 min | Teach and check: Making a signature | Encrypting a whole document with a private key would be slow. Model the worked example Signing with the toy key pair on the board, one line at a time. Your turn: A receiver decrypts a digital signature to get one digest, but hashing the message gives a different digest. State two possible reasons. | Pairs |
| 21 to 30 min | Teach and check: What signatures prove | A digital signature on its own does not hide the message; it is often sent as plaintext. | Cooperative Concept Mapping |
| 30 to 36 min | Check | The four Stage 1 questions from the student lesson, answered on mini whiteboards or by show of fingers. Re-teach the one most get wrong. | Individual, then whole class |
| 36 to 43 min | Plenary | The exam-style questions from Stage 2, one at a time: thirty seconds alone, then a random call. The feedback lines in the key give the examiner's wording. | Individual, random call |
| 43 to 45 min | Exit and homework | Set the worksheet below (6 questions, 20 marks). Learners self-assess against the objectives before they leave. | Individual |
Protect the parts that carry the learning
The sequence carries about fifty minutes of material, so the lab is driven by one student while the class predicts rather than explored freely. Times are a guide.
Protected: the check at 30 minutes. It is the only individual read on whether the key idea landed, and it is not cut.
Cut first if the build overruns: the last check in What signatures prove, never the check or the plenary.
In a 60 minute block: run worksheet questions 1 to 3 in class as a Rally Coach set and model both the hardest worked example and its check live.
Cooperative Concept Mapping
Teams receive the key terms on cards and arrange them on a large sheet, drawing and labelling the links. Compare maps between teams before showing the model map.
The full structure, with its variations and the other twelve, is on the cooperative-learning page.
What to head off, and how
| Trap learners fall into | Teaching move that pre-empts it |
|---|---|
| A certificate never contains the owner’s private key. | It carries the public key; the private key must stay secret with its owner. |
| The receiver does not "decrypt the message to check the hash". | They decrypt the signature with the sender’s public key and re-hash the message, then compare the two digests. |
| A digital signature is not a scanned image of a handwritten signature. | It is an encrypted message digest that depends on both the message and the private key. |
Digital signatures and digital certificates: worksheet
6 questions, 20 marks. Written in the style of the papers; no past paper question is reproduced.
Describe how an organisation acquires a digital certificate.
State three items of data contained in a digital certificate.
Explain how a digital signature is produced for an email.
Explain how the receiver of the email uses the digital signature and the sender’s digital certificate to check the email.
A key pair uses n = 55, public key e = 3 and private key d = 27. A received signature is 2 and the receiver hashes the received message to get 9. Determine whether the message is verified.
A software company signs its updates digitally. Explain why a user can trust a signed update, and why the signature alone does not stop a competitor reading the update.
Answer key and marking notes
- The organisation generates a public / private key pair.
- It sends its public key and identifying details (name, domain, address) to a certificate authority.
- The CA verifies the organisation’s identity.
- The CA creates the certificate, signs it with the CA’s private key and issues it.
- The owner’s public key.
- The owner’s name / organisation / domain name; the issuing CA’s name.
- Serial number, validity dates or the CA’s digital signature (any one per mark, max 3).
- A hashing algorithm is applied to the email.
- This produces a fixed-length message digest.
- The digest is encrypted using the sender’s private key.
- The encrypted digest is the digital signature, sent with the email (and the sender’s certificate).
- The receiver checks the certificate is valid using the CA’s public key and takes the sender’s public key from it.
- The signature is decrypted with the sender’s public key to give the original digest.
- The received email is hashed with the same algorithm to give a new digest.
- If the two digests match, the email is from the sender and has not been altered.
- Decrypt the signature with the public key: 23 MOD 55 = 8.
- 8 is not equal to 9, so the message is not verified: it has been altered or was not signed with the matching private key.
- Only the company holds the private key, so a signature that verifies with the company’s certified public key proves the update came from the company.
- Any change to the update (e.g. inserted malware) changes the digest, so tampering is detected.
- The signature is an encrypted digest, not encryption of the update itself, so the update can still be read; confidentiality needs separate encryption.
6 multiple-choice questions on this lesson
From the topic question bank. Assign them in the app for a marked score in your gradebook, or run the topic as a class game.
Which item is included in a digital certificate?
- AThe owner’s public key
- BThe owner’s private key
- CThe session key for the next connection
- DThe message digest of the owner’s last email
How is a digital signature produced for an email?
- AThe email is hashed to a digest, which is encrypted with the sender’s private key
- BThe email is hashed to a digest, which is encrypted with the receiver’s public key
- CThe whole email is encrypted with the sender’s public key
- DA scanned image of the sender’s handwritten signature is attached
A receiver decrypts a digital signature with the sender’s public key to get digest A, then hashes the received message to get digest B. A and B are different. What should the receiver conclude?
- AThe message was altered in transit or was not signed with the sender’s private key
- BThe message is genuine, but it was encrypted with the wrong session key
- CThe sender’s certificate has expired, so the hash algorithm has changed
- DThe message is genuine, because the signature could be decrypted
How does a browser check that a website’s digital certificate really was issued by a certificate authority?
- AIt checks the CA’s signature on the certificate using the CA’s public key, which is built into the browser
- BIt asks the website to send the CA’s private key for comparison
- CIt checks that the certificate contains the website’s private key
- DIt decrypts the certificate with the website’s private key
A sender’s toy key pair uses n = 55, public key e = 3 and private key d = 27. The digest of a message is 7. What is the digital signature, and how is it verified? (Encryption: valuekey MOD n.)
- A727 MOD 55 = 28; the receiver checks that 283 MOD 55 = 7
- B73 MOD 55 = 13; the receiver checks that 1327 MOD 55 = 7
- C727 MOD 55 = 28; the receiver checks that 2827 MOD 55 = 7
- D7 × 27 MOD 55 = 24; the receiver checks that 24 × 3 MOD 55 = 7
An attacker intercepts a signed message from a bank, changes it, signs the new digest with the attacker’s own private key and attaches a public key labelled with the bank’s name. Why does a careful receiver reject it?
- AThe attacker’s key comes with no certificate from a trusted CA confirming that it belongs to the bank
- BThe attacker’s new digest cannot match the changed message, because hashing is random
- CSignatures made with any private key can be decrypted only by the bank
- DThe message is still encrypted with the bank’s session key, so the change is visible
Quiz key
The certificate binds the owner’s identity to their public key, along with a serial number, validity dates, the CA’s name and the CA’s signature. The private key is never included or shared. Session keys are created fresh for each TLS session and are not stored in certificates. Message digests belong to individual signed messages, not to the certificate.
Hashing gives a short fixed-length digest, and encrypting it with the sender’s private key means only the sender could have produced it, while anyone can check it with the sender’s public key. Using the receiver’s public key would give confidentiality, not proof of sender. Encrypting with the sender’s own public key is pointless, as only the sender could decrypt it. A scanned image is not a digital signature and can be copied.
Matching digests show the message is unchanged and was signed by the private key holder, so a mismatch means one of these has failed: the message was changed, or the signature was not made with the matching private key. Session keys belong to TLS and are not part of signature checking. An expired certificate does not change the hash. Being able to decrypt the signature is not enough; the digests must also match.
The CA signs each certificate with the CA’s private key; browsers and operating systems ship with trusted CAs’ public keys, so they can verify the signature. A CA’s private key is never given to websites. Certificates never contain private keys, and the browser never has the website’s private key.
The digest is encrypted with the private key: 727 MOD 55 = 28. The receiver decrypts with the public key: 283 = 21952 and 21952 MOD 55 = 7, which matches the digest. Signing with e = 3 would let anyone make the signature, and the receiver would need d to check it, which it does not have. Checking with d again is impossible for the receiver, who has only the public key (and 2827 MOD 55 is not 7 anyway). The keys are exponents, not multipliers: 7 × 27 MOD 55 is 24, and 24 × 3 MOD 55 is 17, not 7.
The attacker’s signature verifies with the attacker’s own public key, so the maths alone would pass; what fails is trust in the key, because no CA will issue a certificate binding the attacker’s key to the bank’s identity. Hashing is deterministic, so the attacker’s digest does match the changed message. A signature is decrypted with the signer’s public key, not specially by the bank. Session keys belong to TLS and are not part of signature checking.
Slides for this lesson
A projectable deck for every pack is on the way. Until then, present the student lesson full screen: its sections, figure and lab tabs follow the same order as the plan above.