2 ms·
I agree on the TPA not using the secure element on the phone is an issue, but I wasn't addressing low quality authenticator apps, but for apps or for tokens you
by olliej 4y ago
I agree on the TPA not using the secure element on the phone is an issue, but I wasn't addressing low quality authenticator apps, but for apps or for tokens you're assuming that the developers haven't cheaped out.
> A smartphone OS ...
Yes, and the same applies to tokens albeit with simpler logic, and the same applies to any PC. So at some point you're saying "I trust that the company producing the product I'm using is not lying in their security documentation".
> .. Reviews ...
Correct, because reviewers are talking about feature set, competent phone companies provide extensive documentation of the security architecture of the devices. Security researchers periodically write up their investigations.
> These are opaque devices, with a huge attack surface.
No, by the standards you have presented all your devices are opaque, but unlike every other device you own the default security model of a well designed phone is far stronger than any other device you have. They don't run arbitrary code, they don't support loading code into kernel space, user partitions are completely separated from the read only system partitions, etc.
- denton-scratch 4y ago> all your devices are opaque Point taken. I'd take a maximum transparency keyfob-type device. By "maximum transparency", I mean I'd have to be able to assemble it myself, from COTS components, and understand any software it runs. But I have no idea how to make such a thing (I've tinkered a bit with microcontrollers and TTL). The closest I'm aware of is the fob my bank gave me; it has a number-pad and a display, you read a challenge off the screen, and trype it into the keypad. It displays numeric response, and you type it into the website form. That seems cool, if I could build the device myself, or even know what it does.