Bas Wijnen wrote:
>> 1) "soft" rfkill by just politely asking the RF chip to refrain from
[...]
> IMO this is good enough.
Ron K. Jeffries wrote:
> your option 4 has IMO most desirable functionality
Very good, we already have the whole range :-)
About the trust and threat model of Anelok (Y-Box will have to be a
little bit different): everything inside the MCU is trusted, data and
code. Some of the MCU content (the firmware loader/updater) is
permanently and irrevocably (*) protected against modification. Keys
and firmware can be be changed but only if the change is properly
authorized. (Change has a recognized signature and the user confirms
the change. There be no "auto-run" ;-)
The RF SoC is semi-trusted, similarly any electronic communication that
leaves the device. "Semi-trusteds" mean here that secrets may be sent
in the clear over such an insecure channel if the users wants this. But
there will also be the possibility to only allow secure commonication.
The memory card is not trusted [1]. What is - reluctantly - trusted is
the user interface, i.e., display and the capacitative sensor. The user
needs these already for operational security, e.g., to unlock the
device, to command the sending of passwords, and so on. Passwords can
be displayed (optional) or entered on the device, in which case this
information can be spied on, too.
Now, a spy inside the device would have to decode the display updates
and/or the weak analog signals on the capacitative sensor. This may be
a bit of a challenge, especially since any additional chips would be
noticeable - especially if a seal like the one I described a few days
ago is applied.
A spy outside could try to catch electromagnetic noise the device emits
or just look at the screen or watch the user use the information shown
on the screen.
Doing bad things with the RF SoC is easier. E.g., someone could change
its firmware and make it do interesting things, e.g.,
- respond to a specific query packet with the corresponding answer. The
query could come from the circuit in a backpack full of explosives
conveniently left near your way to work. The receiver would -
indirectly - make headline news when receiving the "correct" answer
from the then nearby RF SoC.
- the RF SoC could just record what's in the air and replay it later,
either via RF or by reading its memory after the attacker has taken
possession of the device. E.g., to find out what other BT systems you
keep in your fortress.
- if RF is used with weak security it could record passwords sent over
it, for later retrieval.
- if RF is used with weak security it could try to weaken that security
even further, e.g., by using session keys known to the attacker.
With the "crowbar" approach, the RF SoC has no way to do anything while
rfkill is on. That is, unless the switch has been tampered with and
doesn't actually cut power to the RF SoC. It would still have to tell
the MCU that the SoC has been powered down, or the MCU wouldn't show an
"RF down" indication (*), and the RF SoC may also have to have a means
to know it's now supposedly dead, to act accordingly, in case the MCU
tries to check. Since doing all this would mainly involve altering two
or three traces, it may be possible to make such a change without
clearly visible alterations. Of course, the seal would have to be
broken, but maybe even that would be just a small incision.
(*) Clear feedback that the switch has been operated is crucial. Else,
an attacker could just disable the switch, which would probably
leave hardly any trace.
Without "crowbar", the RF SoC is fully operational in rfkill and can be
interrogated by the MCU. For example, the MCU can read its Flash content
and compare it with the (signed) image on the memory card. Or maybe the
RF SoC itself keeps a signed hash around.
If the RF SoC can escape being put in debug mode, e.g., by diverting the
reset signal to a different pin, it could emulate the debug protocol and
lie about its internal state. E.g., it could try to compress the
original firmware and have the malicious code sit in the area gained.
What all this still requires is a small hardware change (besides the
tricky firmware "extension"). So a seal would still have to be broken.
In the absence of hardware tampering, 2 through 5 should be equally
secure.
- Werner
[1]
http://media.ccc.de/browse/congress/2013/30C3_-_5294_-_en_-_saal_1_-_201312291400_-_the_exploration_and_exploitation_of_an_sd_memory_card_-_bunnie_-_xobs.html
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
