Keycard is an open-source hardware wallet for managing private keys and signing transactions. It takes the form-factor of a credit-card and uses NFC technology for a contactless experience with the Status mobile app.
The previous article in this series gave an overview of Keycard’s security features related to cryptography, access control, smart card security, communication security, applet security and transparency. It described the current implementation, possible exploit scenarios and corresponding mitigations. This article dives into the different Keycard security flows and scenarios.
Security Flows
This section describes security aspects of the various flows while using Keycard with the Status app, specifically the setting up of an account, executing a wallet transaction, logging into the app and exchanging messages.
Account Setup
Status app uses cryptographic keys to keep wallet transactions and chat messages secure and private. These keys are today stored within the Status app on the mobile phone. Keycard enhances security by storing keys within its hardware wallet and using the phone to interact with it. So, even if the phone or Keycard gets compromised, keys are safe.
The account setup flow with Keycard is as follows: keys are generated on the Status app. The user has to pick one of the suggested random but readable three-word chat names which is generated from the chat public key. Keycard is then chosen as the storage location and has to be paired with the phone. For this, Keycard is brought next to the phone to perform three simple but important steps to set it up. First, a 6-digit passcode is created. This is like a password. So a random 6-digit number that can be remembered has to be picked. It should not be something easy to guess like all zeros, 123456 or the user's date-of-birth. The passcode is then confirmed. This passcode will be asked each time a wallet transaction has to be executed.
The next two steps are for the user to safely write down the Personal-Unlocking-Key (PUK) code and pairing-code. As explained in the previous article, these security measures raise the bar significantly for an attacker. And like always, the user has to safely backup the 12-word seed phrase which is required to recover keys if necessary. The app then randomly asks for two of those words to check if the user has indeed written it down correctly.
Wallet Transaction
Once the Keycard account is set up, wallet transactions can be signed using it. The information entered by the user on the Status app is used to create a transaction specifying the from and to addresses, the crypto token e.g. ETH, the amount of token and the network fee. This transaction has to be signed with the wallet's private key which is now stored only within the Keycard.
When ‘Sign with Keycard’ is tapped, the app communicates with the Keycard over NFC and starts authorizing this transaction. It shows the secret three-word signing phrase (not to be confused with the three-word chat name) which informs the user that this transaction signature request is indeed coming from the Status app and not someone else spoofing it. This signing phrase is generated randomly for every app installation and first shown to the user during setup.
The user now has to enter the passcode to authorize this transaction. If the passcode is correct, the Keycard signs the transaction sent to it by the Status app. Note that the wallet's private key never leaves the Keycard. The transaction is signed with the key and sent back to the Status app to further forward it to the Ethereum network for confirming the transaction on the blockchain.
App Login
Users can unlock the Status app with the Keycard. The user has to tap the Keycard on the phone (i.e. bring it near the phone) and enter the 6-digit passcode to get into the Status app. This effectively brings two-factor authentication (2FA) to Status app by combining what-you-have, i.e. Keycard, with what-you-know, i.e. passcode.
There is no longer the option of using a password like earlier. If one wants to use Keycard only for signing transactions but not for 2FA login to Status app, they will have to rely on the phone’s biometric feature to get into the Status app.
Chat
All chat messages are encrypted with the chat key as described in the previous article. The chat key is generated on the Keycard but is exported (during setup) to the Status app so that the app can automatically encrypt/decrypt every message without requiring it to be sent to the Keycard and having the user enter passcode each time.
Security Scenarios
This section describes the various security scenarios that could potentially arise while using Keycard with Status app such as losing the phone or/and Keycard, or forgetting one or more of the Keycard access credentials. It also suggests remediation measures.
Lost Phone
The Status app on the lost phone does not store any wallet private keys because they are now stored on the Keycard. So the wallet assets are safe. The only key within the Status app is the exported chat key. But to send messages, the attacker has to first get past the phone's authentication and then Status app's authentication. If Keycard was enabled for 2FA then the attacker will need the Keycard and passcode — this raises the bar significantly.
The remediation for the Keycard user is to pair the Keycard with the Status app on a different phone using the saved pairing-code from setup and continue to use the Keycard with the same passcode/PUK-code like earlier.
Note that the user’s chat message history on the lost phone along with contacts and profile information will be lost unless they had synced their phone earlier. So it is recommended to have a backup phone synced.
Lost Keycard
The lost Keycard, now potentially with an attacker, cannot be paired with the attacker's device to access the original wallet because that requires both the pairing-code and passcode which are not available to the attacker.
The Keycard can technically be reset and paired again with another device by starting the initialization procedure all over again but this procedure creates a new seed phrase, pairing-code and passcode. So effectively, there is a way for an attacker to take over the hardware, but never the original wallet's seed phrase — the original wallet's assets are safe.
The remediation for the Keycard user is to initialize a new Keycard with the same seed phrase as earlier to restore the private keys controlling the assets. Recovery is currently possible but inconvenient because it requires the user to reinstall the app. We are improving this process in a future release where the user can recover only using the seed phrase without having to reinstall the app.
Lost Phone and Keycard
If the user loses both the phone and the associated Keycard to an attacker, the attacker still does not have the credentials required to unlock the user's phone (assuming the user had enabled such a feature) or the Keycard passcode required to log into Status app and authorize the signing of transactions.
Brute-forcing the passcode beyond three times freezes the Keycard requiring the PUK-code. Without the PUK-code, brute-forcing it beyond five attempts further blocks the Keycard forever.
The remediation for the user is to initialize a new Keycard with a different phone but the same seed phrase as earlier to restore the private keys controlling the wallet assets.
Forgot Passcode or PUK-code
If the user forgets the passcode, the saved PUK-code can be used to reset the passcode.
If the user forgets the passcode and the PUK-code then the Keycard will have to be reinitialized with the wallet's seed phrase. Note that Keycard and Status app currently do not support this reset functionality. So for now, the Keycard is effectively useless and the user has to reset with a new Keycard or fall back to using a wallet without it.
If the user loses the PUK-code but has the passcode, the PUK-code can be reset using the Keycard Connect tool.
Forgot Pairing-code
If the user forgets the pairing-code, it will not be possible to pair the Keycard with a different device. Keycard use will be restricted to the user's current device with which they've already initialized and paired.
The user can however use the passcode to change the pairing-code using the Keycard Connect tool, but only if Keycard Connect was already paired earlier.
Forgot Seed Phrase
If the user requires the seed phrase to reinitialize a new wallet with the original wallet's assets but forgets or loses the seed phrase, the assets are confined to the original wallet. If access to the original wallet is also lost, the assets are stuck.
If the user still has access to the original wallet then it is recommended to create a new wallet with a new seed phrase, transfer original wallet assets to this new wallet and safely backup this new seed phrase. The original wallet without any assets can then be abandoned.
Keycard does not have access to the seed phrase at any point. For now, it is generated on the Status app and the user is required to back it up only once after which it is permanently removed from the app.
Damaged Keycard
If the Keycard is physically damaged then the user can pair the Status app with another Keycard and initialize it with the same seed phrase (as the earlier Keycard) to access the original wallet contents. This scenario is the same as the lost Keycard one.
Malware on Phone
Keycard security relies on the paired device and Status app being trustworthy. If the paired phone has malware which can subvert the Status app, steal the passcode, impersonate the paired Status app (i.e. trojans) or bypass the pairing enforcement at the OS level, then it can execute unauthorized transactions from the Keycard when it is within NFC range.
The threat model considered here is quite severe because it assumes, for e.g., zero-day keylogging malware (that have bounties reaching a million dollars) which is custom built for Status app and Keycard scenario. Even if the user’s phone is partially compromised, Keycard provides enhanced security by isolating the wallet keys from the phone.
While this risk is potentially magnified on rooted phones, we believe that this is of low probability given the App store checks and policies. But as always, the user is advised to exercise caution while installing apps of questionable origin or intent.
Summary
Keycard has been designed with the highest security in mind. This article describes the different security flows and scenarios which users may encounter while using Keycard with Status app.
For anything else that’s not covered in this article, there is also the Keycard FAQ, community forum on Discuss or the #support channel in Discord.
Status team strives to continually improve the security posture of Keycard as we explore more features and applications for it. If you have any suggestions or questions, please feel free to reach out to us at security@status.im.
(Thanks to Andrea Franz, Corey Petty, Hester Bruikman, Michele Balistreri and Tobias Heldt for reviewing drafts of this article and providing helpful feedback. Thanks to Alex Howell for the thoughtful illustrations.)
