Hardware password manager or how to stop entering passwords and start living
My name is% username%, I'm n years old and I'm paranoid. And every day the information world complicates my life. There is more technology, the threshold of entry into IT is reduced, and we get a reality, where gross security errors are normal. And also the power of computing is growing every year. As a result, our passwords, stored as it will turn out, become public.
Security is not dead, but is encapsulated and agonizing. And every year the knocking on the lid of the black box is quieter, and the choked screams are no longer audible at all. It hurts a lot of abstractions over.
We do not know how the next service stores our passwords, so we ourselves must take care of our security, but it also becomes more and more difficult every year. And the number of services required for a comfortable life is only growing. And for everyone you need to have your strong and unique password. This was not my personal life.
')
Therefore, we came up with our hacker approach to storing and entering passwords.
Briefly: the phone is connected via Bluetooth with a special device that emulates a keyboard. Loss of the device and the phone does not allow to get passwords. The loss of the device and the master password is also not terrible. How so? Welcome under the cat (there are 7 pictures, but they are pretty).
Character passwords are a legacy that will be used by a large number of services for quite a long time. I will not even begin now about the fact that not all people_ who_programm use the correct techniques for storing passwords on the server.
For the most part, I solve the problem of the convenience of entering a password. And this is more important than it seems.
When you come up with a password, you always keep in mind that later it may be necessary to enter with your hands. For example, if this is the password for an encrypted disk with the OS. Or for authorization in your favorite operating system. Even the same password entry from the phone will be a pain in the fingers for a 16-character password with characters and letters in different registers. And all this may force you to use some kind of simplification, which will reduce the strength of the password.
Some password managers allow you to fill in some fields automatically. But no program manager will work without a loaded operating system that allows you to run foreign binaries. Moreover, it is impossible to collect manager code for all existing operating systems. Which leads to the problem of the impossibility of automated password input in a large number of uskeys.
Here are some of them:
Actually, a hardware password manager was invented with the ability to store and enter passwords of up to 128 characters. If you do not consider the principles of the system (which provide security in case of loss of devices), then the hardware manager emulates the keyboard and enters the password selected from the phone. Communication between devices via Bluetooth.
The system consists of three devices.
Home computer (MAIN_PC) with a program on it:
Phone with Bluetooth (PHONE) and the program:
Special Device (PSD):
PSD stands for Paranoia Satisfaction Device
How to enter passwords into the system:
The base is duplicated. After the passwords are written to the program, 2 base files will be created and another base will be recorded in the PSD. The first base remains on the computer to prevent the loss of passwords. The second must be transferred to the phone.
How to use it all:
After that, PSD will enter the password. The computer will think that the password is entered from the connected hardware keyboard.
And now the really interesting part. We must make it all safe. Of course, you can’t make an unbreakable system, but you can minimize the number of attack vectors, which we will do.
The goals that I set for the system:
To paraphrase, we come to the concept: you need to have all the data and devices that the user has to get passwords. The manager should never lower security.
Let's start with the base on the computer. This is the first thing that the user creates and everything is trite in it. This is just encrypted JSON. Encryption - AES256 / CBC / PKCS7Padding. In the near future we plan to switch to the KeePass format.
Do not forget that from any device can be considered memory. Therefore, to store passwords in the clear on the PSD can not in any case. But encryption is of little help, since then the password will be stored in the same memory. Therefore, the decision was chosen not to store full passwords in general (except for the backup database on MAIN_PC).
The password storage algorithm is very simple:
As a result, for each password we get 2 parts (password_part_1, password_part_2), whose XOR will give us the original password (with padding from \ 0 at the end). Since we have a lot of passwords, password is an array. Accordingly, we will have an array of password parts on each device.
password_part_1 [i] ⊕ password_part_2 [i] == password [i]
We will store the first parts (password_part_1) on the phone and password_part_2 on the PSD. To enter the password, we will send password_part_1 [PassId] via Bluetooth and XOR with password_part_2 [PassId] on the PSD. In this way, we will get a password using the PassId index, which we will enter on the computer (FOREIGN_PC), emulating a hard keyboard.
But what if the hacker decides to intercept traffic and steal the PSD. He can still read the memory from the EEPROM and get passwords, parts of which he got from the traffic. So traffic must be encrypted (not very original, yes).
Traffic must be encrypted so that if you lose your PSD, you cannot decrypt packets. The problem is that the hacker knows everything that PSD knows. If PSD can decrypt traffic using information on it, then the hacker will be able to decipher the traffic. We will use one-time keys, updated with each new package. PSD will have a key only for the next package, but not for the one received earlier. Initially the same keys are set by the computer (MAIN_PC) when writing databases.
BtKey and HBtKey are keys for encrypting and verifying package integrity. They both change with each message. The integrity check is based on the SHA256 based HMAC. The key for him is HBtKey [i]. To encrypt the packet itself, use AES256 / CBC / PKCS7Padding. In the packet, password_part_1 and PassId are transmitted. Also in the package there are keys for decrypting the next package (HBtKey [i + 1], BtKey [i + 1]).
As soon as the packet gets on the PSD and is decrypted, the telephone will immediately generate an answer. This is sha256 (HBtKey [i]). HBtKey [i] is the previous key for HMAC. Then passwords in the PSD memory are replaced with new ones (i + 1). And a password is entered on FOREIGN_PC.
After that, the phone sends the answer that everything is entered correctly (sha256 (HBtKey [i])) and the phone deletes the old keys, replacing them with new ones.
More lists for god lists:
The result is that the passwords for decrypting packets already sent no longer exist. There are only passwords to decrypt the next packet.
It turned out quite comfortable, interesting and safe thing.
Unfortunately, I can not describe the entire system in one article. I have already gone beyond 13k characters, and told only the basic concept of a common system. If this article was interesting to someone, then I can write another one that will cover the rest of security. There are quite interesting approaches.
The application on the phone also has some interesting features that help keep the balance between security and convenience (access to the encrypted database has only a service that allows you to enter a password once and apply different reset policies. For example, 30 minutes after entering).
And the device will be able to launch custom firmware to implement any functionality that is required (for example, a bluetooth usb keyboard). And there are also some interesting things about security approaches.
Now we have a working prototype of the device, firmware on the device, an Android program and two programs (gui and console) on the computer.
Computer programs are written in .net and works well under mono. But under Linux, the library I use to communicate with the PSD does not see the device, but I plan to fix it.
All code for the phone and for the computer is open. It can be found on the githaba .
We have the following plans:
We are going to continue to engage in the project, but it would be very interesting to know the opinion of the habrasoobshchestva about the prospects. There are a lot of people among my acquaintances who would like to use such a device, so I have the prerequisites to conduct a small survey.
By the way, in the described protocol there is a logical vulnerability. It can not be operated remotely (easier to put the keylogger) and it is fixed without crutches. You can try your hand at finding this vulnerability (the vulnerability is logical, and not at the code level) and we promise to give the first person who finds it a ready device (if we start mass production).
Naturally, in the case of release, this vulnerability will be closed.
Answer hash: 28dbc42aa86100dc5e325c4bea80c67c980cfd26
Security is not dead, but is encapsulated and agonizing. And every year the knocking on the lid of the black box is quieter, and the choked screams are no longer audible at all. It hurts a lot of abstractions over.
We do not know how the next service stores our passwords, so we ourselves must take care of our security, but it also becomes more and more difficult every year. And the number of services required for a comfortable life is only growing. And for everyone you need to have your strong and unique password. This was not my personal life.
')
Therefore, we came up with our hacker approach to storing and entering passwords.
Briefly: the phone is connected via Bluetooth with a special device that emulates a keyboard. Loss of the device and the phone does not allow to get passwords. The loss of the device and the master password is also not terrible. How so? Welcome under the cat (there are 7 pictures, but they are pretty).
DISCLAIMER
This is not a promotional article. This is a description of the solution that I invented and implemented with my colleague. The purpose of this article is to describe an interesting solution to an existing problem and collect opinions about it from the IT community.
PSD is NOT a replacement for cryptographic tokens. These are completely different areas. Here we are talking only about character passwords that will be entered automatically through keyboard emulation.
PSD is NOT a replacement for cryptographic tokens. These are completely different areas. Here we are talking only about character passwords that will be entered automatically through keyboard emulation.
What problem i solve
Character passwords are a legacy that will be used by a large number of services for quite a long time. I will not even begin now about the fact that not all people_ who_programm use the correct techniques for storing passwords on the server.
An example of a safer password storage method.
hash (hash (pass) + user_id + salt)
For the most part, I solve the problem of the convenience of entering a password. And this is more important than it seems.
When you come up with a password, you always keep in mind that later it may be necessary to enter with your hands. For example, if this is the password for an encrypted disk with the OS. Or for authorization in your favorite operating system. Even the same password entry from the phone will be a pain in the fingers for a 16-character password with characters and letters in different registers. And all this may force you to use some kind of simplification, which will reduce the strength of the password.
Simplification example
ICloud users can easily be calculated by their passwords, as they often have an uppercase first or last letter. Often used name and date of birth / age
How to solve the problem before me
Some password managers allow you to fill in some fields automatically. But no program manager will work without a loaded operating system that allows you to run foreign binaries. Moreover, it is impossible to collect manager code for all existing operating systems. Which leads to the problem of the impossibility of automated password input in a large number of uskeys.
Here are some of them:
- OS not yet loaded
• OS disk is encrypted
• partitions with OS are encrypted - Authorization required in OS
- OS does not allow the use of storage devices (corporate policy)
- OS prohibits the execution of any custom code (corporate policy)
- OS is not supported by password manager
• uncommon OS
• outdated OS
PSD from the user's point of view
Actually, a hardware password manager was invented with the ability to store and enter passwords of up to 128 characters. If you do not consider the principles of the system (which provide security in case of loss of devices), then the hardware manager emulates the keyboard and enters the password selected from the phone. Communication between devices via Bluetooth.
Slightly more
The system consists of three devices.
Home computer (MAIN_PC) with a program on it:
Phone with Bluetooth (PHONE) and the program:
Special Device (PSD):
PSD stands for Paranoia Satisfaction Device
How to enter passwords into the system:
- Connect the PSD and telephone to the host computer
- Using a special program to record your passwords in the database
- Transfer one of the received databases to the phone
The base is duplicated. After the passwords are written to the program, 2 base files will be created and another base will be recorded in the PSD. The first base remains on the computer to prevent the loss of passwords. The second must be transferred to the phone.
How to use it all:
- Connect PSD to usb of any computer to which you need to enter a password (FOREIGN_PC)
- In the application on the phone, select the password that you want to enter
After that, PSD will enter the password. The computer will think that the password is entered from the connected hardware keyboard.
Security psd
And now the really interesting part. We must make it all safe. Of course, you can’t make an unbreakable system, but you can minimize the number of attack vectors, which we will do.
The goals that I set for the system:
- Loss of PSD, phone or both devices will not reveal user passwords and will not allow to decrypt intercepted bluetooth traffic
- Imperceptibly for the user, it is impossible to get the base with PSD
- If a master password leaks, losing one of the devices will not reveal passwords.
To paraphrase, we come to the concept: you need to have all the data and devices that the user has to get passwords. The manager should never lower security.
Storage
Let's start with the base on the computer. This is the first thing that the user creates and everything is trite in it. This is just encrypted JSON. Encryption - AES256 / CBC / PKCS7Padding. In the near future we plan to switch to the KeePass format.
Do not forget that from any device can be considered memory. Therefore, to store passwords in the clear on the PSD can not in any case. But encryption is of little help, since then the password will be stored in the same memory. Therefore, the decision was chosen not to store full passwords in general (except for the backup database on MAIN_PC).
The password storage algorithm is very simple:
- We write 128 random bytes to password_part_1
- Make the user password XOR with password_part_1 and get password_part_2
As a result, for each password we get 2 parts (password_part_1, password_part_2), whose XOR will give us the original password (with padding from \ 0 at the end). Since we have a lot of passwords, password is an array. Accordingly, we will have an array of password parts on each device.
password_part_1 [i] ⊕ password_part_2 [i] == password [i]
We will store the first parts (password_part_1) on the phone and password_part_2 on the PSD. To enter the password, we will send password_part_1 [PassId] via Bluetooth and XOR with password_part_2 [PassId] on the PSD. In this way, we will get a password using the PassId index, which we will enter on the computer (FOREIGN_PC), emulating a hard keyboard.
Traffic encryption
But what if the hacker decides to intercept traffic and steal the PSD. He can still read the memory from the EEPROM and get passwords, parts of which he got from the traffic. So traffic must be encrypted (not very original, yes).
Traffic must be encrypted so that if you lose your PSD, you cannot decrypt packets. The problem is that the hacker knows everything that PSD knows. If PSD can decrypt traffic using information on it, then the hacker will be able to decipher the traffic. We will use one-time keys, updated with each new package. PSD will have a key only for the next package, but not for the one received earlier. Initially the same keys are set by the computer (MAIN_PC) when writing databases.
BtKey and HBtKey are keys for encrypting and verifying package integrity. They both change with each message. The integrity check is based on the SHA256 based HMAC. The key for him is HBtKey [i]. To encrypt the packet itself, use AES256 / CBC / PKCS7Padding. In the packet, password_part_1 and PassId are transmitted. Also in the package there are keys for decrypting the next package (HBtKey [i + 1], BtKey [i + 1]).
As soon as the packet gets on the PSD and is decrypted, the telephone will immediately generate an answer. This is sha256 (HBtKey [i]). HBtKey [i] is the previous key for HMAC. Then passwords in the PSD memory are replaced with new ones (i + 1). And a password is entered on FOREIGN_PC.
After that, the phone sends the answer that everything is entered correctly (sha256 (HBtKey [i])) and the phone deletes the old keys, replacing them with new ones.
More lists for god lists:
- The phone generates BtKey [i + 1] and HBtKey [i + 1]
- EncryptedPayload = AES256 (key: BtKey [i], input: PassId || password_part_1 || BtKey [i + 1] || HBtKey [i + 1])
- EncryptedMessage = IV || EncryptedPayload || HMACsha256 (key: HBtKey [i], input: EncryptedPayload)
- phone sends EncryptedMessage packet to PSD
- PSD decrypts EncryptedMessage using BtKey [i] and verifies integrity with HBtKey [i]
- PSD generates a response to the phone (but does not send). Response = sha256 (HBtKey [i])
- PSD changes its HBtKey [i] and BtKey [i] to new ones, obtained from the package (i + 1). Old ones are deleted
- PSD collects the password (password_part_1 ⊕ password_part_2 [PassId]) and enters it on the computer (FOREIGN_PC), pretending to be a keyboard
- PSD sends response to phone
- The phone checks the response and changes the keys to new ones.
- i ++
The result is that the passwords for decrypting packets already sent no longer exist. There are only passwords to decrypt the next packet.
Conclusion
It turned out quite comfortable, interesting and safe thing.
Unfortunately, I can not describe the entire system in one article. I have already gone beyond 13k characters, and told only the basic concept of a common system. If this article was interesting to someone, then I can write another one that will cover the rest of security. There are quite interesting approaches.
The application on the phone also has some interesting features that help keep the balance between security and convenience (access to the encrypted database has only a service that allows you to enter a password once and apply different reset policies. For example, 30 minutes after entering).
And the device will be able to launch custom firmware to implement any functionality that is required (for example, a bluetooth usb keyboard). And there are also some interesting things about security approaches.
Now we have a working prototype of the device, firmware on the device, an Android program and two programs (gui and console) on the computer.
Computer programs are written in .net and works well under mono. But under Linux, the library I use to communicate with the PSD does not see the device, but I plan to fix it.
All code for the phone and for the computer is open. It can be found on the githaba .
We have the following plans:
- Based on the results of your reaction, evaluate the need for the device and what components we can allow to use there
- Support for setting passwords from everything that has mono (Linux, Mac OS)
- Switch to KeePass format for base on MAIN_PC
- Bluetooth 4.0
- The ability to collect the base, having only the phone and PSD
- Ability to add passwords from the phone
- Ability to synchronize passwords without MAIN_PC
We are going to continue to engage in the project, but it would be very interesting to know the opinion of the habrasoobshchestva about the prospects. There are a lot of people among my acquaintances who would like to use such a device, so I have the prerequisites to conduct a small survey.
Vulnerability Scan
By the way, in the described protocol there is a logical vulnerability. It can not be operated remotely (easier to put the keylogger) and it is fixed without crutches. You can try your hand at finding this vulnerability (the vulnerability is logical, and not at the code level) and we promise to give the first person who finds it a ready device (if we start mass production).
Naturally, in the case of release, this vulnerability will be closed.
Answer hash: 28dbc42aa86100dc5e325c4bea80c67c980cfd26
Source: https://habr.com/ru/post/276967/
All Articles