Close
0%
0%

Zamek: The Offline Pocket Password Manager

Creating and retrieving passwords for all your accounts has never been this easy and convenient!

Similar projects worth following
Zamek is your personal, portable password manager.

I'm working on putting together a group-buy campaign for a batch of these with attractive cases! Sign up at https://www.crowdsupply.com/soniktech/zamek to find out when you can get your own!

See a video review of the beta unit at https://www.youtube.com/watch?v=gLEXId6XHqc !

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.

  • 1 × ATMega32u4 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × OLED screen
  • 1 × Custom designed circuit board
  • 1 × Lithium battery
  • 1 × Custom designed enclosure

  • Video Review

    jarek3196 days ago 0 comments

    I sent a spare Zamek beta unit to a Youtube Electronics Channel; check out their take on it here!

  • Back On Track!

    jarek3196 days ago 0 comments

    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!

  • Final Hardware Revision

    jarek31909/09/2016 at 02:35 8 comments

    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.

  • PCB and Assembly by MacroFab, Launching on CrowdSupply!

    jarek31905/10/2016 at 03:17 0 comments

    Latest PCB Revision, fabbed and assembled by the fine crew at www.macrofab.com !


    I'm working on putting together a group-buy campaign for a batch of these with attractive cases! Sign up at https://www.crowdsupply.com/soniktech/zamek to find out when you can sign up for your own!

    This project will release its source files, containing board layout, source code, and enclosure designs, on the day the campaign launches, all published here on https://hackaday.io/project/3555-zamek-the-offline-pocket-password-manager !

    See all the details: https://hackaday.io/project/3555-zamek-the-offline-pocket-password-manager

    Here is a video showing the screen layout and data entry using the joystick: https://hackaday.io/project/3555-zamek-the-offline-pocket-password-manager/log/33748-drum-roll-please

    There is also a PC app planned which will provide backup and restore to hard disk functionality, as well as make inputting credentials to your Zamek easier: https://hackaday.io/project/3555/log/36334-pc-app-is-functionally-finished

  • Short delay as I'm waiting for displays to arrive

    jarek31904/27/2016 at 13:57 0 comments

    The next PCB revision is in, but my display vendor has delayed shipment of my order. Expect pics of the new revision some time next week!

  • Adding Storage and Increasing Security

    jarek31904/21/2016 at 00:20 0 comments

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

  • PC App is Functionally Finished!

    jarek31904/20/2016 at 05:09 0 comments

    All the features are finished and tested: reading and editing individual accounts, and full encrypted EEPROM dumps and restores. Now to give it a good helping of UI design :)

  • PC-based Credential Entry

    jarek31904/15/2016 at 20:55 0 comments

    One of the biggest 'asks' has been "can I use my PC to enter the credentials more quickly?"

    Now you can. Still a WIP, need to clean up the UI and figure out how to do terminators, but it definitely works!

  • Case Design

    jarek31904/10/2016 at 19:58 0 comments

    Test fitting a new case design

  • Case Design

    jarek31904/03/2016 at 16:40 2 comments

    In no particular order, different versions of what I'd like the case to look like. Testing before injection molds are made is easy when you have a 3d printer :D

View all 14 project logs

Enjoy this project?

Share

Discussions

Steveo wrote 02/14/2017 at 20:59 point

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

  Are you sure? yes | no

jarek319 wrote 6 days ago point

Sorry for the late reply; just restarted the case work :)

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 :)

  Are you sure? yes | no

GNUtoo wrote 04/10/2016 at 21:21 point
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.

  Are you sure? yes | no

jarek319 wrote 04/10/2016 at 23:45 point

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.

  Are you sure? yes | no

GNUtoo wrote 04/10/2016 at 21:14 point
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.

  Are you sure? yes | no

jarek319 wrote 04/10/2016 at 23:41 point

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

  Are you sure? yes | no

castvee8 wrote 04/05/2016 at 00:39 point

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. I gave you a like!

  Are you sure? yes | no

jarek319 wrote 04/05/2016 at 00:54 point

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 :)

  Are you sure? yes | no

napiorek wrote 11/21/2016 at 14:26 point

Don't bother with moulding, nowadays cost of 3D print of such a small case is affordable.

  Are you sure? yes | no

Sam Partridge wrote 03/16/2016 at 11:41 point

I've been doing some research for my very own password manager and came across the PBKDF2 algorithm which might be useful to you. It runs your password through a hashing algorithm many times to take a reasonably long time to compute. The function also accepts a salt which allows you to use a string to create different passwords for the same pin. In this device the salt could be the website name.

As an example WPA2 WiFi security uses PBKDF2 with 4096 iterations*. For an 8 bit 16MHz microcontroller you would probably need a lot fewer iterations otherwise it would take several minutes to calculate your password. Alternatively you could use a more powerful microcontroller.

*source https://en.wikipedia.org/wiki/PBKDF2

  Are you sure? yes | no

Sam Partridge wrote 03/16/2016 at 13:20 point

I've just realised that you're encrypting/decrypting passwords instead of generating them on the fly, so I'm not sure how applicable this would be. It's an interesting read nevertheless :)

  Are you sure? yes | no

jarek319 wrote 03/16/2016 at 14:01 point

I think this is great, thank you! I'm looking through every possibility, and while the device can (now) generate random passwords too, I'll look into this as an alternative to on-the-fly en/decryption :) I may end up swapping out the atmega for a cortex m0+ once I get more interest in this ;)

  Are you sure? yes | no

Daniel Gilbert wrote 01/04/2015 at 09:57 point

Really like the idea of an independent device for this task. It should be as lightweight as possible, so that you could attach it to your keychain or sth.

Maybe you've already stumbled upon this, but just in case: I really like the "Masterpassword App", and here is it's algorithm described: http://masterpasswordapp.com/algorithm.html

  Are you sure? yes | no

jarek wrote 01/04/2015 at 18:43 point

Thanks :) The plan is to keep it no larger than a car key fob, maybe smaller!

The inplementation that Masterpasswordapp uses is pretty similar to what I was going to use, unfortunately a real world scenario popped up when I had to update my family's family plan account, so this system has to be able to also store arbitrary passwords and encrypt them as well, while preventing pin retrieval brute forcing attacks....

  Are you sure? yes | no

Daniel Gilbert wrote 01/04/2015 at 22:01 point

Yeah, I encountered a similar problem. I'm looking forward to the finished Password Manager. :)

  Are you sure? yes | no

Dimitris Zervas wrote 12/10/2014 at 05:47 point
How secure is the method you use?
Also, how many passwords can you save?

  Are you sure? yes | no

jarek319 wrote 12/10/2014 at 07:59 point
I still need to recruit a security researcher to give their stamp of approval and fill in a few blanks. Since the passwords are generated individually using the user as a source of entropy each time, even somehow getting your hands on a dump of the data would not be an issue, as the password is encrypted using the user's PIN. The final algorithm I'll end up using to decrypt the password with the PIN is the last step and arguably the most important. Stay tuned!

Right now i'm only using the Trinket's built in 1KB EEPROM for storing 21 site/user/pass combination entries, but I'm going to be upgrading it to an external I2C EEPROM once I get this proof of concept ready.

  Are you sure? yes | no

Dimitris Zervas wrote 12/12/2014 at 09:35 point
I just wrote an implementation of the xxtea "tiny encryption algorithm".
It needs some security patches, but, I think that it's a good starting point.
Take a look: http://git.dzervas.gr/libxxtea
It can be used both as encryption dectryption algorythm but also to provide you some more randomness (apart from the entropy).

  Are you sure? yes | no

jarek319 wrote 12/17/2014 at 04:10 point
Just got back to the lab, it looks interesting! Mind if I incorporate it into the project? I'll give you credit of course :)

  Are you sure? yes | no

Dimitris Zervas wrote 12/24/2014 at 10:14 point

It's under the beerware license, so you can do it whatever you want! :)

I am yet a bit concerned about the security of xxtea. Take a look at RC4, it may be a stream encryption, but I think does a better job than xxtea...

  Are you sure? yes | no

Dimitris Zervas wrote 12/24/2014 at 10:38 point

update: take a look here http://avrcryptolib.das-labor.org/trac/wiki/AES!

Decrypts AES 256 in 10k cycles (or 5k if you use fast), which means 1/1600 seconds!

If it fits in your MCU, you MUST use AES, it's the best!

  Are you sure? yes | no

PointyOintment wrote 12/05/2014 at 09:37 point
I disagree with your tagline:

66
Creating and retrieving passwords for all your accounts has never been this easy and convenient!
99

I use LastPass, which can automatically fill in my username and password and click the "log in" button as soon as I load the site. I don't see how this can be more convenient than that.

  Are you sure? yes | no

jarek wrote 12/05/2014 at 17:55 point
I have many passwords for places where lastpass "doesn't go", such as numerous Windows/Mac/Linux log in screens, BIOS passwords, phone lock screen, work phone lock screen.... And that's just what I need in the morning!

I think the next breakthrough would be how I avoid clutter using this system: my LastPass account used to have about 200 entries before I finally moved to my current system, so even navigating to my lastpass account on my smartphone to find additional passwords was a chore.

  Are you sure? yes | no

PointyOintment wrote 12/06/2014 at 02:04 point
Ah, good points. Will this emulate a keyboard, then? And how will you find entries on it (i.e. input a website name to get a password)?

I do like the idea of generating passwords dynamically by selecting from a large random table according to a PIN. I'm not sure about the security implications of that, though.

  Are you sure? yes | no

jarek319 wrote 12/07/2014 at 23:25 point
Navigation is the secret sauce to this project :) Stay tuned!

Keyboard emulation will be one of the first things I will add after making sure the security of the generated passwords is acceptable for tech folks like us. It is a Trinket Pro after all, so it should be an easy addition.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates