Completed: ICDevs.org Bounty #27b - NoKeyWallet - Rust - up to $10k

LiveDuo · November 16, 2022, 9:35am

We have made significant progress with the library.

Here’s the repository:

So far we’ve built the main functionality to create (and store) EVM addresses and sign (and store) transactions on behalf of the canister. We also added support for Legacy, EIP1559 and EIP2930 transaction types and different chain ids (eg. Ethereum testnets, Avalanche, BSC etc).

Up next:

Handle nonce differently for each EVM chain
Add more unit tests
Add two more e2e tests (for creating a smart contracts / ERC20 transfers)
Work on the “no key wallet” example canister to make more visually pleasing

Might also be a good time to have a look on the repo just to check we are on the same page. Also, what should we call the rust crate for this library?

skilesare · November 17, 2022, 2:37am

Guys…this looks amazing so far. I don’t have a great answer on the Rust question as I don’t know my way around that ecosystem much. Can a rust dev make a comment?

paulyoung · November 17, 2022, 3:24am

I don’t know much about the EVM but I took a quick look and had some initial thoughts on the randomness and private keys in the wallet:

I imagine it’s better to use the randomness from the IC instead of the getrandom crate
- Here’s an example: ic-auth-tokens/lib.rs at 76113cbaa8b788b1989a9d5ef0868cdb12ee46af · codebase-labs/ic-auth-tokens · GitHub
People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

neeboo · November 17, 2022, 7:07am

Maybe supporting standard derived path would be much better. We will open-source something soon, we can discuss later

ccyanxyz · November 17, 2022, 10:04am

This can be useful: GitHub - rocklabs-io/ic-web3: Ethereum RPC client for canisters on the IC, ic-web3 can help access Ethereum RPC endpoints and sign/send Ethereum transactions from within canisters.

skilesare · November 17, 2022, 2:29pm

This particular package is using t-ecdsa I believe.

paulyoung · November 17, 2022, 3:54pm

I don’t think so:

github.com

nikolas-con/ic-evm-tx/blob/e21cf38c8e2775e47f0001f36f1af6afb6d8c66c/lib/no_key_wallet/Cargo.toml#L15-L15


      
          getrandom = { version = "0.2.8", features = ["js"] }

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L60-L68


      
          //! ### WebAssembly support
          //!
          //! This crate fully supports the
          //! [`wasm32-wasi`](https://github.com/CraneStation/wasi) and
          //! [`wasm32-unknown-emscripten`](https://www.hellorust.com/setup/emscripten/)
          //! targets. However, the `wasm32-unknown-unknown` target (i.e. the target used
          //! by `wasm-pack`) is not automatically
          //! supported since, from the target name alone, we cannot deduce which
          //! JavaScript interface is in use (or if JavaScript is available at all).

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L70-L74


      
          //! Instead, *if the `js` Cargo feature is enabled*, this crate will assume
          //! that you are building for an environment containing JavaScript, and will
          //! call the appropriate methods. Both web browser (main window and Web Workers)
          //! and Node.js environments are supported, invoking the methods
          //! [described above](#supported-targets) using the [`wasm-bindgen`] toolchain.

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L76-L81


      
          //! To enable the `js` Cargo feature, add the following to the `dependencies`
          //! section in your `Cargo.toml` file:
          //! ```toml
          //! [dependencies]
          //! getrandom = { version = "0.2", features = ["js"] }
          //! ```

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L83-L84


      
          //! This can be done even if `getrandom` is not a direct dependency. Cargo
          //! allows crates to enable features for indirect dependencies.

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L86-L89


      
          //! This feature should only be enabled for binary, test, or benchmark crates.
          //! Library crates should generally not enable this feature, leaving such a
          //! decision to *users* of their library. Also, libraries should not introduce
          //! their own `js` features *just* to enable `getrandom`'s `js` feature.

skilesare · November 17, 2022, 4:03pm

Ah…ok. @LiveDuo we should be using t-ecdsa to sign these in a secure way. It may be ok to have a switch and just use a random key if a dev wants that kind of security, but it is likely not something that would be used in production. (Might be great for testing though).

LiveDuo · November 17, 2022, 6:11pm

@skilesare @paulyoung
We are using the sign_with_ecdsa system call to sign transactions. The getrandom library is only used for getting a random private key in unit / integration tests.

We enabled the js cargo flag because cargo build tries to include the getrandom library and has issues with wasm32-unknown-unknown target.

If there’s a better way to get randomness in unit / integrations tests we are happy to look into it. We will try changing the getrandom dependency to dev-dependencies and see if that works. Also, happy to change the js cargo flag if there’s a better way.

github.com

nikolas-con/ic-evm-tx/blob/master/lib/no_key_wallet/src/lib.rs#L133


      
          let caller = get_derivation_path(principal_id);
          
          
let request = SignWithECDSA {
              message_hash: message.clone(),
              derivation_path: vec![caller],
              key_id: key_id.clone(),
          };
          
          
let (res,): (SignWithECDSAReply,) = ic_call(
              Principal::management_canister(),
              "sign_with_ecdsa",
              (request,),
          )
          .await
          .map_err(|e| format!("Failed to call sign_with_ecdsa {}", e.1))?;
          
          
let rec_id = get_rec_id(&message, &res.signature, &user.public_key).unwrap();
          
          
let signed_tx = tx.signed(res.signature.clone(), rec_id).unwrap();
          
          
STATE.with(|s| {

github.com

nikolas-con/ic-evm-tx/blob/master/lib/no_key_wallet/src/utils.rs#L54


      
          }
          
          
pub fn string_to_vev_u8(str: &str) -> Vec<u8> {
              (0..str.len())
                  .step_by(2)
                  .map(|i| u8::from_str_radix(&str[i..i + 2], 16).unwrap())
                  .collect::<Vec<u8>>()
          }
          
          
#[cfg(test)]
          pub fn generate_random_private_key() -> libsecp256k1::SecretKey {
              loop {
                  let mut ret = [0u8; 32];
                  getrandom::getrandom(&mut ret).unwrap();
                  if let Ok(key) = libsecp256k1::SecretKey::parse(&ret) {
                      return key;
                  }
              }
          }
          #[cfg(test)]
          pub fn create_raw_legacy_tx(arg: EVMTransactionLegacy) -> Vec<u8> {

LiveDuo · November 17, 2022, 6:12pm

People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

Are there actionable things around this? Should we include a warning in the Readme file?

paulyoung · November 17, 2022, 6:18pm

That makes sense. Moving to dev dependencies makes that clearer.

A consumer of this crate might still see that and do the same thing, but my main concern was that the library itself was using it.

paulyoung · November 17, 2022, 6:22pm

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

LiveDuo · November 17, 2022, 6:28pm

Given that it’s just used for creating a private key for testing we can possibly get by without it. An option is to hardcode an example private key for our tests.

LiveDuo · November 17, 2022, 6:33pm

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

There were a few forum discussion about the issue. Might be a good idea to include links to those too.

I came across a discussion about increasing the subnet size for the ecdsa signing canisters a few weeks ago. I was under the impression that the subnet will increase in size to (partially?) mitigate the issue.

LiveDuo · November 17, 2022, 6:43pm

Looking forward seeing how far how you guys gone.

We thought about supporting the standard derivation path and we probably end up doing it. We are thinking about providing two signing functions - one with only the required parameters for those that don’t know Ethereum as much and one with more parameters that gives developers more flexibility.

Do you have any use cases in mind?

paulyoung · November 17, 2022, 9:33pm

I’m trying to understand the motivation for storing the private key. It seems unnecessary.

If that’s the case and you’re relying on tECDSA then I would encourage consumers of the crate to do the same (perhaps by doing that in the wallet?)

LiveDuo · November 17, 2022, 9:41pm

The private key never touches the canister, it’s just for the unit tests. If we remove one test there will be no private key in the crate at all.

We have this because we can’t do the tECDSA create private key call in our unit tests so we have to make a mock function.

domwoe · November 18, 2022, 7:30am

I think that’s a good idea.

LiveDuo · December 19, 2022, 4:34pm

We just pushed the latest changes to the library.

From the previous time we finished:

Proper support for different EVM chains (so the transactions nonce are handled seperately).
More unit tests and e2e tests (including smart contract tests)
Work on the “No key wallet” example project to make it usable (probably most of our time)

Here are some relevant links:

GitHub - nikolas-con/ic-evm-sign: A library to sign EVM transactions on the Internet Computer. (library)
GitHub - nikolas-con/ic-evm-sign-starter: A "No key wallet" example project for the Internet Computer. (“no key wallet” starter project)

Happy to hear what others think

LiveDuo · December 19, 2022, 4:35pm

We also deployed the starter project which is essentially a working “No Key Wallet”.

Feel free to test it out: https://vqbpb-giaaa-aaaap-qaxda-cai.ic0.app/