project idea: portable password safe

EdorFaus edorfaus at
Sat Sep 14 21:55:38 EDT 2013

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 

> - 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...


More information about the discussion mailing list