Which of confidentiality, data authenticity and user authentication do these need: remote configuration of a pacemaker, digital radio control of railway signals, and uploading a GPS track to a public competition ranking?
All three need data authenticity and user authentication; none of them primarily needs confidentiality.
| Application | Confidentiality | Data authenticity | User authentication |
|---|---|---|---|
| Pacemaker remote configuration | Rarely (perhaps for data-protection reasons) | Yes | Yes |
| Railway signal radio control | No, the signal states are hardly sensitive | Yes | Yes |
| GPS track upload | No, the track is meant to be public | Yes | Yes |
The reasoning is the same in every row. A pacemaker setting that is forged, altered or sent by the wrong device can kill the patient, but an eavesdropper who learns "pacing rate 70" gains almost nothing. A forged "track clear" signal can cause a collision, while the signal state itself is visible to anyone standing at the track. A GPS track in a ranking is published anyway; what matters is that it really is the pilot's own, unaltered flight.
User authentication here means entity (instance) authentication: the receiver checks who is sending, not just that the message is intact.
Tip: For any remote control, start from authenticity and freshness. Add confidentiality only when the content itself is secret, as with a military drone's commands.