project idea: portable password safe

EdorFaus edorfaus at xepher.net
Sat Sep 7 15:19:19 EDT 2013


On 07.09.2013 12:48, Werner Almesberger wrote:
> EdorFaus wrote:
>> This made me think of another (fairly recent) RF standard I've been
>> interested in, named DASH7
> 
> Oh, they opened is now. Nice. I'm not sure about 433 MHz, though.
> Don't the antennas get awfully large ?

I don't think they have to be, considering one of the products I've 
seen
that uses DASH7 is the HayTag [1] - a pet tag intended for finding lost
pets - which is supposedly just 37 x 34 x 4.5 mm, and that includes not
only the antenna, but also the MCU and the solar cell that powers it.

[1]: http://haytagstore.com/

Also, I've been considering buying a 433MHz development platform that 
TI
is selling, which is in a wristwatch form factor. IIRC it's got a 
fairly
decent battery life too. (Main reason I haven't yet is lack of time.)


> My idea is to simply reuse the atben/atusb work.

That's probably a good idea; starting from scratch with a new 
technology
would really just be adding another variable for little reason.


>> It only allows for sending keypresses (and releases), which is not
>> quite the same thing, as that only tells you which key (or combo)
>> was pressed, not what character was printed on that key.
> 
> Ah yes, good point. USB HID basically sticks to the virtues of
> the good old IBM PC keyboard. It was a pain back then, so why
> change it.

Heh. Well, it actually makes sense to do it this way, since it's a good
representation of what a keyboard really is and does - and sometimes,
you don't really care which letter is printed on it, as long as you can
recognize the key; or you might have a need to remap it *anyway*.

That doesn't mean it's not a pain sometimes, though. :P


>> This means that the device needs to know which keyboard layout is in
>> use on the PC it is talking to, and the keyboard protocol doesn't
>> give it that info.
> 
> Well, it sort of could. There's the bCountryCode field in the HID
> descriptor that could indicate what kind of "localized hardware"
> you have. Of course, using that would be uncool, so nobody seems
> to.

I wasn't aware of this, but if nobody uses it, I guess it can't really 
be
trusted by the OS, which means it would probably be ignored anyway...


>> The easiest way to do that would probably be to make a setting for 
>> it.
> 
> Yes, that seems to be the best choice. Forced QWERTY would also
> be hugely unpopular with QWERTZ and AZERTY users.

Yep, anyone who doesn't use QWERTY would be really unhappy, even if 
they
did stick with just the basic set of chars.

I guess US QWERTY would be a good place to start though, as long as we
keep in mind that we'll need to be able to map things differently 
later.

And I do mean it when I say differently - not just different key, but
different key combinations. (Example: US QWERTY has ; and : on one key,
one shifted one not. My keyboard has them on different keys, both 
shifted.
Another example: my layout can generate É, but only by pressing 
multiple
keys in sequence; I assume languages that use it often would have it 
more
easily available on their layout.)

Actually, now that I think about it, I think we're going to need to be 
able
to tell the user that a password can't be typed with the currently 
selected
layout, as different layouts can generate different sets of characters.
E.g., I don't think a US layout can generate the Æ, Ø and Å my layout 
can.


Hm, there's an idea - I assume the device will be able to recognize 
which
dongle it's in the vicinity of (since they're paired with keys etc.), 
so
maybe we could have a way to autoselect the layout to use based on 
that?

Most people probably wouldn't need it, but it would be nice for those 
who
use different layouts in different places (e.g. at work and at home)...

Would still need to have settings for that of course... And a way to
override the autoselection.

... Hm, what should happen if the device is in the vicinity of more 
than
one known (and paired) dongle? E.g. if you have one dongle in your work 
PC,
and one in your laptop, and then one day you bring the laptop to 
work...


Oh well, most of that is just software, so we can deal with those 
features
when we have something that works for the basic use case.


> Since it would typically operate in a "almost always off" mode,

That's a good point. With a device like this, and a basic RTOS, it's
probably going to be just as fast to boot each time as it would be to
suspend/resume with something more complex (like Linux), and that makes
it perfectly feasible to keep it completely off most of the time, which
saves quite a bit of power.


> Assuming about 5 minutes of use per day, at an average of 70 mW,
> CR2032 should last about two months, AAA half a year, and AA more
> than a year.

If we make sure it's powered completely by USB as long as the device 
port
is connected to a host, quite a few people might end up using it on 
battery
power even less than 5 minutes per day.

Although, that depends on having them plug it in instead of using the 
RF
dongle... So I guess maybe not all that many people after all. Oh well.

I still think it's a good idea though, as it would make the device 
usable
even when the battery is dead.

Hm, I wonder - would it be feasible to have the device side USB plug be 
a
male A plug on a cord that retracts into the device body? That way the 
user
wouldn't need to carry a cable separately... Oh wait, that's what the 
RF
dongle is for, duh.

-Frode



More information about the discussion mailing list


interactive