On 09/11/2013 05:52 PM, Werner Almesberger wrote:
EdorFaus wrote:
Or, alternately, the device could behave as if the write lock was
off, except that all reads/writes goes to a separate jailed section
Kinda like the journal in a journaling file system ? Yes, that
could be a possibility: collect all changes, then present the
user with a "diff" and ask whether to "commit".
Ah, that's not what I had in mind, but I suppose it could be an option.
What I had in mind was more like, if the device normally saves
everything in one (encrypted) file, then in this mode it would instead
use a different file with completely separate content (modulo some
details[1]) for the PC management interface, while still using the
normal file for the physical display and replay interfaces.
This includes not just writes, but also reads (including lists), to
avoid info leaks.
That way, any malware that tries to read from the locked device would
think it was reading from the user's actual password list, while in
reality it would get dummy data (or no data at all), and any writes it
does wouldn't affect the real passwords either.
To be honest, I'm not so sure that this is really any better than simply
returning an error or not responding at all. I think the idea is based
on an idea I saw somewhere for stopping forum/comment spam[2], so I'm
not sure if the idea is really valid for this use. It does kind of feel
like security by obscurity, since it's based on hiding what's actually
going on.
One negative aspect of this would be that the actual password management
program wouldn't be able to tell the difference either, so if the user
had locked their device and forgot about it, they'd probably be a bit
puzzled as to why their passwords weren't manageable anymore.
[1]: One such detail would be that, if the user has made the device
replay a password on the keyboard interface, that password might as well
be available in the lists, since the PC has seen it anyway, and it not
being there could be an indication of this mode being active.
[2]: That idea goes like this: instead of directly blocking the spam,
pretend that you accept it and then display it on the site as normal
posts - but only to the spammer's IP/account. That should make them
think they succeeded, so they won't keep trying harder to get through,
while no one else actually sees it.
I'd envision basically the following USB protocols:
- password store management
I wonder - would it be practically possible to set this up in such a way
that you can allow access on a per-program basis, instead of allowing it
for the entire PC the device is connected to?
I'm imagining some kind of protocol that would present a random key in
both the program and on the device, that you can compare to see if you
want to allow access to the program with that key.
... Hm, now that I think about it, that probably wouldn't add any real
security, would it? If the PC has malware, that malware might be
infecting the management program itself, in which case the user would
allow access anyway - and if no malware is present, it's not necessary.
I guess giving different levels of access to different (non-malware)
programs on the same PC might be useful, but that can be done in easier
ways.
- DFU to the internal Flash (for development)
Not sure whether regular firmware upgrades should also be allowed
via DFU. In any case, they could come from the memory card.
It's probably safer, in several ways, to only allow regular updates via
the memory card, and DFU only when actually doing development.
It's not even necessary to pull out the memory card anyway - just switch
the device to USB storage mode.
Would DFU enablement be best solved via a device setting or via
compile-time options for the firmware? I'd guess the latter would be
safest against accidental activation, but would also add a firmware variant.
Should it be possible to boot from the memory card? It might make
development easier, as one could have separate cards for dev and normal
use, but it would also open another attack vector...
-Frode
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
