For my own clarity of thought, here are descriptions of the cryptographic systems currently in use by the
Bitcoin Titan. Obviously they may change, and some are missing (like all the schemes for firmware upgrades and such).
Deterministic Key GenerationThe Titan uses a variation of the up-and-coming Chain Code ECDSA key generation schemes. Traditional ECDSA generates key pairs by picking a random integer in the relevant finite field (slightly less than 2^256 in the case of secp256k1 ECC) and using that as the private key. The corresponding Public Key is generated as follows using Elliptic Curve Arithmetic:
Q_a = d_a * G
Where Q_a is the Public Key, d_a is the Private Key, and G is the Generator for the particular ECC field. This scheme requires the generation and storage of every private key one wishes to use. Such a scheme makes backups difficult, requiring the user to create frequent backups to ensure they do not lose any of their private keys as new ones are generated.
In the Titan, a random Base Private Key is generated (using a TRNG) in the usual field, along with a 256-bit Chain Key. Generation of key pairs occurs like so:
Q_b = d_b * G
d_n = d_b + AES(k,n)
Q_n = (d_b + AES(k,n)) * G
= d_b * G + AES(k,n) * G
= Q_b + AES(k,n) * G
Where d_b is the Base Private Key, Q_b is the Base Public Key, k is the Chain Key, n is a 128-bit Chain Index, d_n is the n'th key pair's private key, and Q_n is the n'th key pair's public key. The Base Private Key is kept secret and secure on the Titan and never leaves the device unencrypted (it may leave the device in an encrypted backup). The Base Public Key and Chain Key are shared with any Authorized Clients. This allows the Authorized Clients to generate up to 2^128 Spendable Public Keys (using the last equation above), allowing Authorized Clients to receive Bitcoins. However, without access to the Base Private Key, Authorized Clients cannot send Bitcoins and must defer to the secure Titan to do so.
Typically, Authorized Clients will use Chain Indexes starting from 0 and incrementing by 1 for every new Spendable Public Key needed. This allows the Authorized Clients to re-generate all Spendable Public Keys at a future date using only the data stored on the Titan, and the number of keys to re-generate. In case of data-loss, a Titan user only needs their Titan device, or a backup of it, to completely recover all their Bitcoins.
The usage of AES in this scheme prevents outside observers who do not have access to the Chain Key from knowing which Public Keys in the blockchain belong to a Titan user.
The only information that needs to be backed up in the typical usage of this scheme is the Base Private Key, and Chain Key. Everything else can be re-created on demand. Both of those pieces of data are generated exactly once on the Titan, and so need only be backed up once. This means that a Titan user does not need to keep making constant backups of their wallet(s).
This scheme, in its typical application, also allows Authorized Clients to generate their own keys on demand without access to the Titan. This differs from traditional ECDSA key generation in that access to the private key store must be granted every time a new Public Key is needed.
The risk factor with this scheme of key generation is that a malicious party who gains access to the user's Authorized Client compromises that user's privacy/anonymity. However, this is the case even for traditional key generation. The benefit of using a secure Titan still applies, preventing the malicious party from spending any of the user's Bitcoins.
Atypical usage allows for this system to be used in numerous other creative ways for enhanced security. For example, if the user encrypts their Authorized Client, they can help prevent compromise of their privacy/anonymity. Or, for the ultra paranoid, the Chain Indexes can be generated randomly, instead of deterministicly. This is equivalent to two-factor authentication, requiring that the user have access to both their Authorized Client and their Titan to spend any money. The random Chain Indexes may be encrypted as well. The downside of this atypical usage is that constant backups are again required. Or, the user may choose to never authorize their Client, and instead depend on the Titan to always generate Spendable Public Keys. Or any mixture of these methods, along with CSPRNG generation of Chain Indexes, combined with external multi-factor authentication schemes. Or ... etc.
NOTE: This usage of AES is based on Counter Block Mode ciphering, and as such behaves like a CSPRNG. This differs from other Chain Code schemes that use a simple hash or other not CS scheme. It should not make a difference, though; all that truly matters is that an attacker cannot predict the scalars used. Also note that an IV is not required, since we aren't technically ever reusing the ciphertext.
Transaction SigningTransaction signing can be one of the biggest weaknesses of systems like the Bitcoin Titan. It is important to remember that while the Titan itself, and the information stored on it, is secure, the Client talking to the Titan should not be considered secure. For example, a naive implementation would have the Titan merely receive an arbitrary transaction and sign it. However, this allows an attacker to intercept the transaction before it reaches the Titan, modify the destination address (or any number of other modifications), and then hand it off to the Titan to be signed.
To prevent these kinds of attacks, it is necessary to display all of the
necessary information about a transaction to the user. To this end, the Titan has strict requirements on the types of transactions that it will sign. This is to be extended in the future to support more complex and diverse types of transactions, but for the time being only one kind of transaction is supported. Many input, single output with or without change output.
By restricting the transaction to only a single destination, and possibly a change destination, the Titan can easily display all of the relavant information about the transaction to the user. The Titan needs only to display the amount of money being sent to the destination, and the address of the destination. No other information can be manipulated by an attacker in such a way that the user would lose money.
Each input of the transaction is given to the Titan along with the relevant scriptPubKey (from the referenced Outpoint), and Chain Index. The change output, if it exists, is not given to the Titan as a scriptPubKey, but is instead given as a Chain Index. This prevents an attacker from specifying their own address as the change address. By specifying a Chain Index, the Titan can be sure that the change address belongs to the user.
N.B. Although the key generation scheme used by the Titan, described above, allows for Chain Indexes up to 2^128-1, this presents a risk factor to the user. An attacker could specify a change Chain Index as some random 128-bit number. Though the resulting change address would technically belong to the user, it would be impossible for the user to find the corresponding 128-bit chain index. To prevent this type of attack, the Titan will typically restrict Chain Indexes to 32-bits. 2^32 chain indexes could easily be brute forced if need-be by the user.
The Titan returns a fully signed transaction, which any Bitcoin Client can broadcast to the network.
BackupsSince the data on the Titan may be encrypted, backups (which only need to occur once) can be made directly from the Titan's datastores.
Titan EncryptionThe Titan must store on its internal flash the Base Private Key, and Chain Key. Both are encrypted using either keys derived from the user's passphrase, or using default keys. Encryption is performed using AES-256, and authenticated with HMAC-SHA256 (Encrypt-then-MAC). The encryption and authentication keys are derived using PBKDF2-HMAC-SHA256. It is important to note that generation of the derived keys is performed by first deriving a Master Key using a high iteration count PBKDF2. The derived keys are then generated from the Master Key. Creating the derived keys directly from the the user's passphrase reduces the effort required by attackers to crack the keys, and increases the effort required by the Titan to generate the keys.
Cracking the AES encrypted Base Private Key and Chain Key is estimated to be more difficult than usual, since the data being encrypted is completely random. The only way to verify that an attempt is correct is for the attacker to also have a sample Spendable Public Key generated from that data. Even then, the attacker must incorporate ECDSA calculations into his brute-forcing attempts, increasing the computational complexity and requiring specialized (and thus not likely optimized) software/hardware. Attacking the HMAC is more straightforward, and is likely to be the primary target of brute forcing attacks. Paranoid users who store backups of their encrypted Titan data may choose to discard the HMAC, making brute force attempts more difficult.
A user may choose to encrypt their backups with a second layer of encryption of their choosing, using a different key.
NOTE: The Titan stores TRNG generated salts for the relevant CS functions.
EmulationIf a user finds themselves in a position where all they have is a backup of their Titan, but no Titan to restore the backup to, it is possible to emulate all the behavior of the Titan in software. Though this is obviously insecure, it could be performed on a cold, air-gaped machine in case of emergency.
Additional Risk FactorsThe Titan system is designed to secure the
spending of Bitcoins. It is not designed to aggressively secure the
receiving of Bitcoins. What I mean is that an attacker can install malware on a user's computer that can do any one of a number of things to trick the user into giving out the attacker's receiving addresses instead of the user's own receiving addresses. (Fill the wallet with the attacker's public keys, manipulate the clipboard when copying addresses, etc). The Titan allows the user to verify and confirm the sending of any Bitcoins, but it doesn't stop these types of receiving attacks.
In the future, the Titan could be enhanced to help fend off these types of attacks. It could generate and/or display receiving addresses itself, preventing interference by a malicious party, for example.
