← Secret messages

Defend the door lock

A radio door lock has three weaknesses. Find each one, name the tool from this course that fixes it, and build the fixes in milestones.

Security teams run 'red team, blue team' exercises. The blue team defends: they audit their own system, find where it is weak, and fix it before anyone else can find the same weakness.

This is the blue team challenge: you defend a system you own. Below is a radio door lock: the key micro:bit sends the door code, and the lock opens if the code is right.

It works. Your job is to audit it (find its weaknesses), then harden it with what you have built.

PredictRead the code and say what it will do before you run anything. A wrong guess is fine: it shows you what to look for.

Predict

The program as blocks
Show as code
lock.ts
radio.setGroup(5)
input.onButtonPressed(Button.A, function () {
    radio.sendString("OPEN 4271")
})
radio.onReceivedString(function (receivedString) {
    if (receivedString == "OPEN 4271") {
        basic.showIcon(IconNames.Yes)
    } else {
        basic.showIcon(IconNames.No)
    }
})
A is pressed on the key micro:bit. A third micro:bit in the same radio group is switched on. Which micro:bits can read the door code 4271?

RunRun it and compare the result with your prediction.

Run

The program as blocks
Show as code
lock.ts
radio.setGroup(5)
input.onButtonPressed(Button.A, function () {
    radio.sendString("OPEN 4271")
})
radio.onReceivedString(function (receivedString) {
    if (receivedString == "OPEN 4271") {
        basic.showIcon(IconNames.Yes)
    } else {
        basic.showIcon(IconNames.No)
    }
})
Try it yourselfYour edits are saved in this browser.
It takes a few seconds to load. Your work in this step is kept.

InvestigateTrace how each line of code connects to what you see.

Audit

The program as blocks
Show as code
lock.ts
radio.setGroup(5)
input.onButtonPressed(Button.A, function () {
    radio.sendString("OPEN 4271")
})
radio.onReceivedString(function (receivedString) {
    if (receivedString == "OPEN 4271") {
        basic.showIcon(IconNames.Yes)
    } else {
        basic.showIcon(IconNames.No)
    }
})

Match each weakness of the door lock with the tool that fixes it.

The code 4271 goes out as plain text, so every micro:bit in the group can read it
The lock can't tell a damaged or changed message from a real one
The same message opens the lock every time, so one that was heard once works again

Which fix needs the key to be agreed beforehand, or by a key exchange?

ModifyChange the code on purpose and check the result.

Milestone 1: lock the code

Send the code locked with secretKey instead of as text, and have the lock unlock it before checking.

Try it yourselfYour edits are saved in this browser.
It takes a few seconds to load. Your work in this step is kept.
Need a hint?

A sends 4271 ^ secretKey as a number.

Another hint

On radio received number, open if received number ^ secretKey is 4271.

The code is locked with the shared key and the lock unlocks it before comparing.

This ticks by itself when your blocks do what is asked.

MakeBuild something new using what you have learned. Expect a few tries; that is normal.

Milestones 2 and 3: harden it

Replace the locked code with a knock that carries a keyed checksum. The lock goes on only if the checksum matches.

Need a hint?

A sends the word KNOCK as a name with its checksum: radio send value (KNOCK, checksum(KNOCK)). The lock only goes on if the checksum matches.

Instead of a fixed code, the lock sends a random challenge; the key answers it, and the lock opens only on the right answer. The functions checksum and answer are already in the starter: you built them in earlier lessons.

Need a hint?

The lock picks randint(10, 99), sends it as CHALL, and the key micro:bit sends back answer(value) as ANSWER. The lock opens only if the answer is answer(challenge).

Try it yourselfYour edits are saved in this browser.
It takes a few seconds to load. Your work in this step is kept.

The knock carries a keyed checksum and the lock checks it.

This ticks by itself when your blocks do what is asked.

A new challenge each knock, answered with the secret key; the lock opens only on the right answer.

This ticks by itself when your blocks do what is asked.

Info

Report

Every protection in your lock rests on one secret key. Security is the habit of asking "what could go wrong here?", then fixing each answer.

Your final lock fixes three weaknesses. Which one weakness is still there, however well you build it?

For teachers

Students audit a radio door lock, match each weakness to a tool from the course, and harden it in three milestones: a cipher, a keyed checksum and a challenge and response. About 60 minutes.

Open the teacher guide: answers, solutions, slides and a worksheet.

Students will be able to

Before class

The idea: the course's three tools answer three different questions: who can read it (a cipher), was it changed (a checksum with a key) and is this a fresh message from someone who has the key (challenge and response). A secure system usually needs all three.

Framing: this is the defender's job. Students audit and harden their own system. The lesson does not have them attack each other's locks. If students want to test each other, run it as 'pass the pair': swap pairs' final locks, and try the real key against the lock; the lock should open for the key and refuse everything else.

The final system: the key micro:bit knocks with a keyed checksum; the lock checks it, sends a random challenge, the key answers using the secret key, and the lock opens only on the right answer. The secret key never crosses the air.

Limits to say aloud: these are classroom versions. The XOR step reveals the key if someone knows both a locked and an unlocked value; the answer function is not a one-way function; keys have to be shared safely first (the key exchange lesson). Real systems use proven tools, not ones we invented.

Challenge milestones: Milestone 1 has most of the code; milestone 2 outlines; milestone 3 gives goals only. Students who finish quickly can add the lockout from the Challenge–response lesson.

Running the lesson

  1. Audit: ask students to say each weakness in their own words before they pick the tool.
  2. Milestone 3: students must see that the old 'OPEN' code is gone; the answer replaces it.

The hard part (on purpose)

Matching each weakness to its tool and keeping the keys the same on both sides. When the lock fails, ask them to name the weakness each milestone fixes.

When students get stuck

Stretch and support

Stretch: Add the lockout after three wrong answers from the Challenge–response lesson.

Support: Share the milestone 2 code and ask students to explain it before they build milestone 3.

Where it leads

Where this leads: real systems use proven libraries, long keys, hash functions and certificates. The ideas here are the same.

What each step is for

Now you can
You reached the endBack to Secret messages