Armory and AI vulnerabilities

[RoadStress]

Is Armory at risk of having the same issues as the recent COLDCARD ones? Or other types of issues that could be found by AI?

[un_rank]

No, that was an isolated incidence as much as I can tell with certain coldcard products(MK3/MK4/Q/MK5) which were created without a passphrase or dicerolls, this not a wide spread wallet issue to cause panic.

You can take precautions by adding a passphrase with whatever wallet you use to serve as extra security. Before doing this read extensively on it and always store the phrase in a different location from where your seedphrase are stored.

There's no correlation between this recent issue and AI.

- Jay -

[nc50lc]

For clarification, it's Coldcard's firmware's entropy generation vulnerability that's exploited to reproduce its users' mnemonic seed.
Armory doesn't utilize Coldcard's code whatsoever.

If ever it has any unnoticed bug, it'll be totally unrelated to the current issue with Coldcard.
Of course, we'll need a reliable code security audit for that.

[Karl_3000]

Is Armory at risk of having the same issues as the recent COLDCARD ones? Or other types of issues that could be found by AI?

Just know that only Coldcard was affected, a wallet that is close source but reproducible which should be a reason it should not be used at all but some people will not listen until they learn with what happened. Coldcard has never been a good wallet since it was close source.

Just use passphrase on all your wallets to make it safe from similar Coldcard attack.

[goatpig]

Is Armory at risk of having the same issues as the recent COLDCARD ones?

At its heart, the coldcard issue is bad entropy, which is the worst kind of vulnerability in cryptography. This is because so long as it is known you've used weak entropy, anyone can attack you. Attackers do not need to breach your system first. The issue didn't exist at first in coldcard at first, it was introduced by successive rewrites of the codebase, where the primary purpose to migrate software license. There is no known entropy issue at the time in Armory.

Or other types of issues that could be found by AI?

Think of AI as throwing a million security experts at a piece of software. The general expectation should be that if there are vulnerabilities, they will be found. In the long term this is a good thing, as it reduces the surface for 0-day attacks. This is where only the attacker is privy to the vulnerability, so he has plenty of time to exploit it.

In the now, I would be lying if I told you I know for a fact there are no vulnerabilities in Armory.
I believe the wallet, signing and underlying cryptography code are free of vulnerabilities, with a high degree of confidence, but I don't know.
I am always looking for new steps to increase that degree of confidence, and I stake my own coins on it, but all I can honestly offer you is a degree of confidence.
If you cannot read code or will not do your own audit of the code, all you get to rely on is mine and others' degree of confidence.

This is why institutional custodians use key ceremonies and multisig setups, where each set of keys is generated with a different piece of software/hardware. At the extreme tip of secure setups, no one trusts a single piece of software/hardware to secure coins. It's always a mix of them, to reduce the impact of unknown vulnerabilities.

[jojo69]

Thank you, I just logged in to ask these exact questions.

I appreciate your candor on the unknoability of unknowns...AI has developed in ways that few of us predicted.

If I might, what exactly is the source of our entropy?

[goatpig]

Thank you, I just logged in to ask these exact questions.

I appreciate your candor on the unknoability of unknowns...AI has developed in ways that few of us predicted.

If I might, what exactly is the source of our entropy?

It ended up taking me more time than expected to formulate an answer, when accounting for transparency and the difference in pre/post 0.96.5 change in implementation and crypto library.

Common part shared across versions

Entropy at wallet generation is the mix of a PRNG pull from the crypto library and one of two sources of extra entropy.
 - The crypto library pull always tracks down to an OS pull.
 - The extra entropy source is either an explicit card deck shuffle when available (0.95+, card shuffle tab in wallet generation wizard), or extra sources of accumulated entropy.
   * It consists of 3 parts:
      1. list of timestamps for mouse and keyboard events since ArmoryQt start
      2. set of sizes, timestamps and filenames of user system temp folder + possibly some system log file hashed content
      3. screenshot of desktop
   * The data is concatenated together and HMAC'd
   * Ignores failure to gather data and/or empty pool, across any of the extra steps.
   * While the position in code varies, the extra entropy code is the same across versions.

0.96.5

 - Extra entropy request and generation:
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/ui/Wizards.py#L166
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/ArmoryQt.py#L1078

 - cryptolib pull:
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/armoryengine/PyBtcWallet.py#L904

   . Leads to, cpp side:
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/EncryptionUtils.cpp#L75

   . Which is Crypto++ fortuna implementation (X9.17, using AES). auto seeded, non blocking.
     Fresh seed everytime since it's a local variable, and extra entropy forces a reseed too.
      + The typedef:
         * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/EncryptionUtils.h#L118
      + The constructor arguments + reseed (all defaults):
         * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/cryptopp/osrng.h#L101

   . Crypto++ version copied into repo.

 - Fortuna seed pulls BLOCKSIZE bytes from OS:
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/cryptopp/osrng.cpp#L77
   + Windows: the usual MicrosoftCryptoProvider + CryptGenRandom
   + Linux/OSX: reads from /dev/urandom
   + Failures are not silently on reseed pull or identical generation across AES blocks

 - AES blocksize is 16 bytes, hardcoded here:
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/cryptopp/rijndael.h#L13
   . All entropy sources are eventually hashed together (down to 32 bytes) then clamped to AES blocksize (down to 16 bytes)

- extra entropy notes -
   . extra entropy is SHA256'd into a fresh fortuna seed (IncorporateEntropy leads to a reseed):
   * https://github.com/goatpig/BitcoinArmory/blob/v0.96.5/cppForSwig/EncryptionUtils.cpp#L84


0.97

 - Extra entropy request and generation:
   * https://github.com/goatpig/BitcoinArmory/blob/dev/ui/Wizards.py#L298
   * https://github.com/goatpig/BitcoinArmory/blob/dev/ArmoryQt.py#L1055

 - cryptolib pull -
   . Python does not touch the root anymore, only provides the extra entropy.
      * https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/PyBtcWallet.py#L484

  . Pulls 32 bytes, cpp side:
      * https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BridgeAPI/Wallets/Manager.cpp#L408

   . Which goes over to libbtc:
      * https://github.com/libbtc/libbtc/blob/master/src/random.c#L86
      + Windows: MicrosoftCryptoProvider + CryptGenRandom
      + Linux/OSX: reads from /dev/urandom or /dev/random depending on what's available on system at build time
      + Will not fail silently on bad pull
      + No fortuna or hashing, raw pull is returned

   . libbtc built alongside on Armory on the same system. Revision hash: 07933995eb5010a016c75fb703a66023116013a3 (HEAD of master branch as of this writing)

 - extra entropy notes -
   . Linux: second entropy pull will not work on Wayland distros, needs addressed
   . screenshot chokes (qt5/6 migration snafu)
   . hashed then XOR'ed into the OS RNG pull:
   * https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BridgeAPI/Wallets/Manager.cpp#L411

Notes on OS sources

 - Microsoft's CryptoProvider: closed source, nuff said
 - Linux/OSX: /dev/urandom can theoretically get exhausted. Unlikely, even more so for 32 bytes of data. Both implementation fail explicitly if they can't pull enough data.

Conclusion

 - This is a standard, run of the mill implementation for the OS pull, even the closed source Windows implementation. Should be enough on its own, but the Windows closed source pull is untrustworthy (typical).
 - Implicit extra entropy is robust but can fail silently. Still decent amount of extra entropy across all OS variants.
 - Explicit extra entropy is good if the user sticks to actually shuffling a deck of cards. Don't pick the cards manually if you're gonna use this, please. Poor value otherwise.
 - Extra entropy is either hashed with or XOR'ed into OS pull, therefor it doesn't degrade OS pull quality.
 - Amount up from 16 bytes to 32 bytes from 0.96.5 to 0.97. This is a paranoid nitpick really, EC over a 256 bits prime field offers roughly 128 bits worth of security.
 - Note: should consider implementing the OS pull directly in the Armory code instead of letting the crypto lib do it, just for code readability.

[jojo69]

Thank you, that clearly did take some work.

I appreciate your efforts.

I clearly have some reading to do.

Build here is 0.96.5 beta, but I suspect that keys may have been generated with an even earlier version.

[goatpig]

The PRNG code has barely changed from inception up to 0.96.5. It uses a local copy of the crypto library used by some of the first Bitcoin client releases (Wei Dai's Crypto++), same version as in Bitcoin 0.5.0 I think? The code wrapping around the PRNG pull hasn't changed either. If you have a target version, I can check, but I'm 99% confident it's effectively the same code under the hood.