Details

Many people use the same password for different online accounts. Even if the password is very strong, hackers don't need to break into your very secure financial and other important accounts directly. They can attack a weaker website, such as a web forum or subscription service, and use the password they stole from that website's database to steal your identity and log into any of your online accounts.

Both physical and electronic security are difficult skills to master, but most would agree that it's a bad idea to use a single key for every real-world lock you own. So why would you use the same digital key for all of your electronic locks? Many people complain that it is difficult to remember multiple passwords; in the real-world, you don't need to remember how every key on your keychain looks like. So I thought: what if you could have a keychain that keeps your digital keys for you? Zamek is the answer.

I turned to the physical keychain for inspiration, as a physical keychain is already very easy to use. When you need to unlock something, you choose the right key, insert it into the lock, and turn.

Zamek was designed to open your electronic locks as easily as a regular key opens physical locks, with an additional layer of security in case someone other than yourself picks up your digital keychain. The process can be described as:

1. Unlock your Zamek using a security PIN you choose

2. Use Zamek's joystick to change the account displayed on its screen to the one you wish to unlock

3. Insert the Zamek into your computer's USB port

4. Press the joystick to enter the password for the account

Zamek will type in the currently selected password into any field on your screen you select. If there is no USB port available, you can read the password for the account on Zamek's highly visible OLED screen and type it in manually.

Entering your account information into Zamek is intuitive and simple. After you enter your information once, it is stored permanently on Zamek's built-in memory. Your information is encrypted with an industry-recognized AES cipher, which means that if your Zamek is ever stolen, criminals will not be able to extract your information.

Zamek was designed to be your electronic key to the digital world. Smaller than a car remote, it easily clips to your keychain and can be carried everywhere. It features a highly visible screen and a long battery life, which is topped up every time you plug Zamek into your USB port. The joystick is comfortable to use, and the interface is intuitive enough to not require an instruction manual after the first set-up. Additional features currently in consideration are secure formatting and backup/restore options.

All the code and schematics for Zamek will be published under an Open Source license. This mean that anyone can read, validate, and critique the design of any part of the Zamek openly. My desire is that the Open Source process will lead to a device which is ultimately more secure, completely trusted, and reproducible in case I am not able to produce these in the future.

Lastly, Zamek is completely yours to own and use. It protects your data in a personal, respectful, and dignified manner: Zamek does not "phone home" to any remote servers, and it does not store any information anywhere other than its secure memory. Your information will never be anywhere but in your pocket.

After a ton of excellent feedback regarding IP68 protection, I have decided to use buttons instead of a trackball for the initial version of the Zamek. I will keep the code for the trackball in comments and possibly revisit it for version 2, but right now my priority is to get this out the door soon!

Exciting news! After much waiting, I've finally found an easily source-able battery to use for the Zamek, meaning I can finally fit together an attractive case :) The first draft of the case has been sent to Ponoko; stay tuned!

Some background: Zamek has been on hold for a while as I searched for ways to easily create a case that fit around the strange shape consisting of the Screen/Battery/PCB sandwich with the trackball right next to it. Every solution that was attempted was either ugly or impractical to produce.

I recently got my hands on some ultra-thin batteries, only 1.5mm thick! These guys don't hold a lot of juice ( 30mAh ), but my calculations estimate that that's enough to check your password about 700 times before you need to top up ( 15 seconds of on-time at 10mA avg draw ). I'm working with the battery manufacturer to see if we can push the charging rate of the battery up to 2 or even 4C, so the battery could be charged in a matter of minutes. Case parts should be in early next week, next update then!

After some back and forths with designing the case, I realized that it would be much easier to produce the device if I re-engineered some of the sticking points around the previous design. So I cleaned up the entire back of the circuit board so that it can sit flush up against the housing. I also added a trackball for faster and more accurate navigation.

A bare ATMega32u4 has 1KB of EEPROM. This means that by itself, it can store 20 typical account entries (consisting of a 16 character site name, a 16 character user name, and a 16 character password). In order to expand this repository, I have added on a footprint for common EEPROM chips. This will allow up to 100 accounts to be stored!

I'm also starting to think of ways to implement an additional layer of security to secure the EEPROM payload against brute-forcing attacks. This usually means taking the route of longer keys and/or longer computation time. I thought about all the literature I've read on the subject and parsed through chat logs with the excellent folks on the Hacker Channel chat, and am thinking about writing a method to encrypt the EEPROM with a very long key that would be stored in the microcontroller's RAM. This key would itself be encrypted with the relatively shorter PIN. This means that if an attacker simply tries to dump the EEPROM, they would be met with a very resistant payload. If the attacker were to try to dump the RAM, they would likely erase the contents of the RAM in the process (I'll give the chip a warm jacket in case security researchers try to freeze the chip ;) ).

@jareklupinski I tried to compile the software, provided via github. Unfortunately that produces errors, because of some missing AES-funktions. Maybe I used the wrong library? Which one did You use for Your program?

Jarek, it's a sadness that you refused the project. I think the IP68 + requirements are too high for this device. to release an ideal device or very close to it, you must release at least one version that can be improved. The project will remain interesting, but only in your photos.

what are you trying to redevelop is very old technology, called token in bank industry, known and in operation for 20+ years. Bank token moved from hardware solution to software app installed on smartphone to generate one-time access code to your bank account. So there is a little chance to sell the same technology and innovation twice.

With cloud solutions, when cloud provider decides to vanish, client stops working and all passwords get lost. … no different really. Only option is to keep them all in your head… and there's only so many most people can store reliably up there.

This is great, count me in for three when available. I'm bad at password management/reuse I try not to be but there is just so much going on in life. I'd really like to see an option to hide the password on screen, maybe have it so that a long press of the trackball reveals the password until you let it go. Anyway thanks for being awesome.

This device looks great and I really hope you succed in competing with other solutions on the market :) One suggestion: I think it would be more secure not to show password on the screen because of possible usage in public space, cafes etc. Also, did you think about making it compatible with mobile devices, e.g. through microUSB adapter? I think this is something the competition doesn't offer yet and would put you ahead of them.

I wandered my way here from N-O-D-E displaying your password manager. It looks great and i cant wait to buy it. Although it may seem very stupid of me to ask, but when do you think it will be ready to be distributed?

No worries about asking :) I'm trying my hardest to get this on CrowdSupply as fast as I can, the latest case prototype actually came in today! I'll get some pictures up soon. If you sign up on the CrowdSupply page they'll send you an email when it's ready too :)

Hi Zamek, just some initial thoughts on a case. I'm guessing pocketable is the goal. So keeping on a key chain/ring. I know you've said about how to protect it. What about a aluminium cage interlaced with thick nija-flex or rubber. Rubber flap to seal the recharge socket. Trouble with rubber is degradation I guess. Solid aluminium is a good conductor but heat I presume is'nt likely to be a massive issue given low power and mostly off functionality. I'm not great with materials but perhaps an alternative would be a simple black anodised solid capped aluminium case instead could give massive durability bar scratches. Again with a flap on one end to keep lint out on the recharge socket. To keep weight down with perhaps a deluxe titanium version !!!

I'll definitely keep metal in mind; it's not the cheapest but definitely the most desirable material!

The entire gadget definitely doesn't produce enough heat to require heatsinking, so even encapsulating the whole thing in rubber would be a solution, however the battery does need a little room to expand, so it would have to be some kind of material that leaves a cavity, is yielding yet watertight, and cheap to produce in quantity... I'll bring it up with my case producer and see what they have on hand that could help :)

Without javascript it messed my linebreak, sorry. Trying to double the line breaks this time.
By the way a feature to consider (or not) would be to have a real RNG on it. There is an implementation here: http://www.gniibe.org/memo/development/gnuk/rng/neug.html I mention it since it might require some hardware modifications.
With PBKDF2, it can be used to verify the passphrase entered with the joystick.

Right now I'm asking the user to click the joystick twice to generate entropy, with the microseconds in between joystick clicks setting the random seed for the atmega32u4's pseudo-rng, but I am evaluating the cost/benefit of a hardware based-rng vs. increasing the number of random joystick clicks required.

Hi,
Having an input device(the joystick) and a display is wonderful.
Thanks to that, maybe that device could also be used like a smartcard,
but without the inherent problems related to it:
Smartcards don't have dedicated displays nor input, this makes it possible
for the host computer to sniff the pin and use it to also sign/decrypt what
the user didn't intend to.
However, I doubt that using encryption and a passphrase could practically speaking
secure the "keychain" content against someone stealing it.
With cryptography, passphrases have to be long to work.
The LUKS FAQ has some information on password complexity.
Entering long passphrases is unpractical with a joystick.
Short but complex passphrases are less practical to remember,
and still an issue to type (Think of having way more characters to select from on
the screen).
An idea would be to do like with old arcade game consoles:
You could make the software generate a random key, which you would encrypt the keychain
content with.
This key would be stored on a memory that can be wiped easily:
Some game arcade consoles uses additional battery powered RAM for that.
Thanks to that tempering can be detected even when your "keychain" is not plugged in
a computer: you can make + and - shorted when the case is opened for instance.
The "additional RAM" data is then lost.
Now, you can also mandate a short password in software, and wipe the "additional RAM"
content if there are too much failed attempts.
Some SRAM are probably power efficent enough to be powered during several years
on coin-batteries.
However, I've no idea how secure this would be: it still seems a better than a very
short password to me.
I've also no idea if it's possible to design a case that would detect tempering,
especially if the attacker tries to cut the case instead of merly opening it.
I don't belive that code signing is practical enough for users to use, since it would
require the users to maintain their own PKI, and to do it securely.
Having someone else to do that would for them would have bad consequences on freedom:
Mandating what code users have to run is not a good idea. That means that they
wound't be able to recompile and run the code, and this is important.
Denis.

I was originally going to type that erasing the contents due to low battery or accidental fault (this is on a keychain, so lots of rough tumbles and shakes) would lead to a lot of angry users who set it off by accident, but I am planning a "backup to pc" feature, so it would actually be possible to randomly generate the key and store it with the backup, so if the contents of the drive are erased, the user would be able to restore a backup from a pc....

I'd have to thoroughly test countermeasures like that against false alarms, but totally do-able :D

Do you have any kind of cost estimate for this? I know it is very premature to ask, but just wondering for a ballpark figure. I am concerned with losing it or the cat stealing it(mine does that) or sitting on it etc.

thanks for the like :) I'm driving the BOM cost down as far as I can, and I'm sending out RFQs to a few injection mold companies. i've never done injection molding, so i have no idea how much that costs yet.

as soon as they come back I'll make an update and give you a figure. but I'll be sure to kitty-test the plastic before I choose it for the case :)