@michele has develop this cool feature in our wallet lite, that upon a tap of the card:
If status is not installed: opens playstore status download page. Video.
If status is already installed : opens status app. Video.
This is really neat in terms of user experience.
We see two options:
We implement features 1 and 2
In this case, we’ll have the factory load up our software package, because in order to have feature 1, our software must be here on the card before status app is downloaded on the mobile
We’ll thus make the installation process a bit faster. However the rest of the initialization remains the same, in particular pairing and PUK secrets are being provided to the user by the app, and he has write them down.
We provide in this case better ease of use, but we also widen our attack surface, because the following attack becomes possible. A malveillant attacker could forge fake status card, and these cards would point out to a fake status app (e.g Status.in) on the playstore. If the user is fooled, his mnemonic either created or imported will be in danger.
We implement only feature 2
In this case, we won’t have necessarily to load the app at the factory, and more importantly the user will still need to download status app by going manually to the playstore.
We need to weigh in the increased ease of use with regards to increased security risk. What do you guys think ? cc @petty
I personally think we can keep both features for our cards, for the main reason that what ever we chose between the two options, an attacker could forge a fake status card with a fake status app, that could launch with NFC to show-up a fake Status playstore page.
I agree with you that a card could be forged in any case, but if we also ship the applet preinstalled then a fake card would be much harder to recognize for the user.
Our task to mitigate the countfeit attack becomes communicating the fact that cards are shipped unpersonalized and are unable to perform any action before personalization. We must communicate this in a way that 3rd parties talking about the hardwallet also mention that. I understand it is not an easy task, but it is a task that can be handled.
The other option is anti-tamper and anti-counterfeit marks and teaching the user how to recognize the correct ones. Then we can preinstall everything. However, this is again, a communication work in addition to the technical and logistic task of creating such marks.
I am talking about mitigation because, of course, there could be user which are more easily fooled or are fooled by people they (wrongly) trust. However this attack could become very real since all our assets are open, so making an exact copy with an added backdoor is trivial work.
My feeling is that the increased convenience for the user of a tap-to-download feature, and thus the overall smoothness of first steps with Status for our users is quite significant.
And for the question which is: how to weight this increased convenience vs the extended security risk? And with regards to how the security risk is increased, I still think that a user who would be fooled by a fake status card pointing to a fake status app, would not know in the vast majority of cases that the real status card can’t be tapped to donwnload-an-app, and thus wouldn’t be less fooled if decided to not have tap-to-donwload on our genuine card.
My take on seals is that they offer decent protection against tampering but not counterfeiting, since they are easy to copy …
We need some more feedback on this. Any one ?
The decision we will take on this will affect the definition of our packaging currently done by @Alex
@guylouis or @michele wondered if this type of Authentication was considered / know for iOS since it’s limited NFC native default capabilities have been expanded for the hardwallet “pro”? Or only Bluetooth is being explored for other reasons?
iOS indeed supports NFC tag reading, and this is what is successfully used with by Yubikey that generates one time password and send them to the iPhone.
However sending information over NFC from the iPhone is still not supported by iOS (it is on Android). And we thus cannot control a smartcard, since we would need to send commands to the card. Since we cannot rely on the fact that iOS will open that in the near future, we have no choice than to have BLE on the Hardwallet Pro.
I feel that having both options is the best course of action, mostly because the increased level of UX is vastly larger than the increase security risk of only doing option 1.
The level of communication that @michele mentions is key though. If users don’t feel comfortable with the tap and download, they can always go directly to our sources and get the app, or build it themselves as we increase the ways in which Status can be obtained.
The thing is that if we want to offer the user the ability to tap-to-download status, this will be pre-installed in the card at the factory. We thus can’t leave the choice open, and have to decide if we provide the card with tap-to-download or not.
Yes, this is something we are discussing. It should probably go hand-in-hand with SNT provisioning to encourage the user to actually validate the card.
