bitcoinj security concept

[jonas.schnelli]

Hi

I still think around how a bitcoinj wallet should be secured by default and what user options should be added.
I'm looking for a solution without 3rd party devices like Trezor.

I'm currently thinking of the following strategy:

Level 1) Basic
- during the very first run (wallet creation), create a random AES key and encrypt the fresh created wallet.
- store the random created AES key in the OS keychain (= encrypted wallet, protected with user login credentials = encrypted filesystem protected with login credentials like mac's "FileVault").
- allow the user to enter a password for protecting his wallet (standard procedure).
- if the user won't enter a password, the wallet is still somehow protected with his login credentials.
- if the user did enter a password, don't store that password anywhere (only users mind).
- if the user did enter a password, change the AES encryption key (derived from password) from the random created standard key to "random-key&user-selected-password" (concat)

Or can bitcoinj handles enc/dec with multiple AES keys?

Level 2) OTP
- If the user likes to improve the security, he could also use a Smartphone to improve encryption
- AES key could be containing three parts (1. random generated password & 2. user selected password & 3. OTP protected password-part)
- the third part of the AES password could only be generated by use a smartphone and a OTP algorithm (i'm currently not familiarly with OTP)
- user must enter the OTP generated on his smartphone AND his user creates password to unlock his wallet

Is this realistic or where do i think wrong?

[Mike Hearn]

If disk encryption is enabled and the users wallet password is stored in the login keychain, isn't that superfluous? The wallet is encrypted on disk by the OS and the disk decryption password is supplied when the user unlocks their screen or logs in. At that point encrypting the  wallet again just adds complexity.

OTP doesn't work how you think it works. Smartphone apps or hardware tokens that generate codes are synchronized with a server. The server checks that the code is what it's supposed to be. But, the server guards the secrets and is assumed to be secure. That's why OTPs are used for login but not for protecting client-side secrets - if the client is compromised, OTPs don't help you.

[jonas.schnelli]

If disk encryption is enabled and the users wallet password is stored in the login keychain, isn't that superfluous? The wallet is encrypted on disk by the OS and the disk decryption password is supplied when the user unlocks their screen or logs in. At that point encrypting the  wallet again just adds complexity.

Must normal uses don't have a encrypted filesystem.
That's why i thought it maybe a good idea to encrypt the wallet with a random passphrase and store the passphase in the keychain. User won't recognize.
But it would make sure, even when the user has not an encrypted filesystem, the wallet is encrypted.
What do you think about that?

OTP doesn't work how you think it works. Smartphone apps or hardware tokens that generate codes are synchronized with a server. The server checks that the code is what it's supposed to be. But, the server guards the secrets and is assumed to be secure. That's why OTPs are used for login but not for protecting client-side secrets - if the client is compromised, OTPs don't help you.

I just thought maybe theres a way of holding a private key in your smartphone app and go over some challenge/response so that you can get a one-time password which then will give you the 3rd part of the passphrase.
But as you said. OTP needs three players: users-computer, users-smartphone (oder key-device) and a server/login-page.

[ganabb]

I am concern about security concept by relying on java as the foundation was a bad move to make as java on my system potential attack surface.

[btcjedi]

In my opinion a bitcoinj wallet already contains all needed user options

[ewittt]

need Some1 hard-forking full verification bugs to be fixed.