Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypted Key Store #1078

Merged
merged 35 commits into from
Apr 29, 2021
Merged

Encrypted Key Store #1078

merged 35 commits into from
Apr 29, 2021

Conversation

connormullett
Copy link
Contributor

Summary of changes
Changes introduced in this pull request:

  • This PR introduces methods to encrypt and decrypt messages and payloads symmetrically. This will further be utilized in the keystore to securely save keys.

Reference issue to close (if applicable)

Closes #1033

Thank you 🔥

@CLAassistant
Copy link

CLAassistant commented Apr 21, 2021

CLA assistant check
All committers have signed the CLA.

@cryptoquick cryptoquick changed the title Connor/1033 encrypted key store Encrypted Key Store Apr 21, 2021
@cryptoquick cryptoquick changed the title Encrypted Key Store Encrypted Key Store (Encryption Methods) Apr 21, 2021
@cryptoquick
Copy link
Contributor

In addition to key_info I think we should have two additional properties on the MemKeyStore struct:

  • unlocked: bool: has it been unlocked yet
  • encrypted_key: bool: it's an encrypted key

@ec2 I'd like your opinions on these:

  1. We may have to introduce checks wherever the keystore is read from to throw if an encrypted key needs to be decrypted. I'm not sure if we should have a default key that's read-only.
  2. Should we introduce checks or requirements for encrypted keys to only work if an HTTP connection is secure?
  3. Should we introduce a requirement for admin, sign, and write keys to require encryption?

I think 2 & 3 these are nice-to-haves, maybe I can put them in a separate issue, when we have the option for running in "production" mode vs "development" mode.

@cryptoquick
Copy link
Contributor

Also @connormullett , check this out:

  • target/release/forest -c ../config.toml -p 1235
  • FULLNODE_API_INFO="/ip4/127.0.0.1/tcp/1235/http" lotus auth create-token --perm admin
  • Take the resulting admin JWT, and replace the one here:
  • FULLNODE_API_INFO="eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJBbGxvdyI6WyJyZWFkIiwid3JpdGUiLCJzaWduIiwiYWRtaW4iXX0.PFlC4lndH_Dw8GitzmTS6nxxGOia_kuefCWHd5FwtR0:/ip4/127.0.0.1/tcp/1235/http" lotus wallet new
  • Then check keystore.json
  • All these private keys should be capable of being encrypted

Though, should we be able to encrypt a private key that's already be written to the keystore, or should we only write freshly encrypted keys?

key_management/src/keystore.rs Outdated Show resolved Hide resolved
cryptoquick and others added 4 commits April 22, 2021 16:12
* WIP RPC API for encrypted keystore unlock method.

* Updates based on PR review feedback.
…e/forest into connor/1033-encrypted-key-store
forest/src/daemon.rs Outdated Show resolved Hide resolved
forest/src/daemon.rs Outdated Show resolved Hide resolved
@cryptoquick cryptoquick changed the title Encrypted Key Store (Encryption Methods) Encrypted Key Store Apr 22, 2021
@connormullett connormullett force-pushed the connor/1033-encrypted-key-store branch from 72c2764 to 5620ac8 Compare April 27, 2021 18:01
@connormullett connormullett marked this pull request as ready for review April 28, 2021 18:51
Copy link
Contributor

@cryptoquick cryptoquick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested it out, it works great!
Great work, @connormullett, and a fantastic first contribution!

@cryptoquick cryptoquick requested review from a user and ec2 April 28, 2021 20:27
}
}
pub enum KeyStoreConfig {
Memory(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we don't need the ()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's fair. I just figured it looked more consistent that way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored.

encryption: None,
}),
KeyStoreConfig::Persistent(location) => {
let file_path = location.join(Path::new(KEYSTORE_NAME));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can just pass KEYSTORE_NAME to join, as it accepts anything that implements AsRef and &str does: https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.join

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. It does seem like if you use encrypted mode, you cant access your unencrypted keys. I wonder if we want that functionality in the future...

While the daemon is running, yes; However, the file still exists. Switching the daemon off to use another set of keys doesn't sound ideal so I agree.

) -> Result<Vec<u8>, EncryptedKeyStoreError> {
let ciphertext = &msg[..msg.len() - 24];

let nonce = match secretbox::Nonce::from_slice(&msg[msg.len() - 24..]) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok_or is perfect for these situations where we want to return an Err in None match arm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it much cleaner (cause ? op). Thanks for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, i love how std lib APIs compose well together

@creativcoder
Copy link
Contributor

Awesome work! Let's get this merged

Copy link
Member

@ec2 ec2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. It does seem like if you use encrypted mode, you cant access your unencrypted keys. I wonder if we want that functionality in the future...

@connormullett connormullett merged commit d245f14 into main Apr 29, 2021
@connormullett connormullett deleted the connor/1033-encrypted-key-store branch April 29, 2021 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Encrypted Key Store
5 participants