4 ms·

I maintain the Fingerprint stack on Google Nexus/Pixel devices. > your fingerprints don't leave the device and are implemented by a piece of hardware in such a

I maintain the Fingerprint stack on Google Nexus/Pixel devices. > your fingerprints don't leave the device and are implemented by a piece of hardware in such a way that even Apple doesn't have access to them. This is true for Google, too. > Compare that to the Android implementations which have fingerprints in the filesystem. They're not stored in plaintext. They're encrypted with keys that remain in hardware. You can never read the keys, only encrypt files with them, from applications running in a separate physical address space, accessible only through the hypervisor. This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor). Implying that Android is somehow less secure in the case of fingerprint is disingenuous.

yayana 9y ago
It sounds like you are saying Nexus devices have a hsm separate from their gsm card for hardware protected keys, do all fingerprint enabled Android devices have this?
- ndesaulniers 9y ago
  I'm not sure what hsm/gsm stand for. I can only speak for the Android devices I work on.
  - jlgaddis 9y ago
    HSM: https://en.wikipedia.org/wiki/Hardware_security_module https://en.wikipedia.org/wiki/Hardware_security_module GSM: https://en.wikipedia.org/wiki/GSM https://en.wikipedia.org/wiki/GSM
    - microcolonel 9y ago
      By GSM you mean the baseband processor, or what?
      - yayana 9y ago
        Every standard (GSM network) phone has a Sim card that is doing some encryption with hardware protected keys. A Sim card for the GSM network. Trying to use it for general encryption might have problems and is more often discussed than done.
        microcolonel 9y ago
        Ahh, just say SIM. GSM is the network, SIM is the module. SIMs are basically just javacards, so having custom crypto applications on them is no big deal, but you need some control of the SIMs your users will want to use in your device for it to be practical.
        yayana 9y ago
        Google is US focused so they presumably still deal with non GSM networks and the possibility of running a fingerprint without a gsm standard SIM. * I.e. there are a lot of issues for Google generalizing encryption via some user provided sim as datails come up. So maybe he is referring to an entirely different crypto module.
gumby 9y ago
First of all, I understand your taking offense (though none was intended) since this is the thing you work on. I feel the same way about stuff I work on! Second, I simply used that as a straightforward example, not to say "Apple good, android bad." Security is always a risk tradeoff. My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys. The house is made of glass so someone could just use a brick to get in. For someone else this is a dumb tradeoff; for me it is appropriate. And your message includes an example of such a tradeoff: >This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor). >Somehow implying that Android is less somehow less secure in the case of fingerprint is disingenuous. The channel between the two separate devices is an attack surface (as is the opportunity for offline attack on the encrypted data in the filesystem). The Android team has made the determination that that's an acceptable risk. I won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously less secure than the single, all-encompassing approach. To claim so is hardly disingenuous. Of course, as with my house, this just changes the class of attack. On either platforms you can consider attacking whatever authentication module talks to the TEE. Both systems use other mechanisms for that. Finally, in the Android case a vendor is free to do what they want, especially if they don't care about access to branding, google services etc. Google branded devices have a more important brand to defend than, say, Asus (not to pick on Asus), much less, say, DJI's drones, for which the Android branding is utterly irrelevant (conceivably that could rebound on Google though personally I doubt it would even happen. The same obviously can't be said about iOS :-)
- ndesaulniers 9y ago
  Those are all fair points, I don't disagree. Maybe disingenuous was the wrong word?
  - gumby 9y ago
    It is completely the wrong word since it describes me to be, at best, deceptive. If you don't disagree you can hardly describe claim I was lying!
criddell 9y ago
> keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor) Why is that?
- ndesaulniers 9y ago
  We don't make our own SoC or Fingerprint Sensor, and time to market.
throwaway25869 9y ago
> They're encrypted with keys that remain in hardware. You can never read the keys, only encrypt files with them, from applications running in a separate physical address space, accessible only through the hypervisor. By 'in hardware', I'm guessing you don't mean real silicon / flash, but rather whatever persistent storage is provided by the SoC vendor's TrustZone implementation. In my opinion calling that 'hardware' implies a level of security and verification that is not actually present, and is disingenuous. If history has shown us anything, it's that relying on a chipmaker's security assurances for platform software features can only end in tears. You don't need to look very far to find real world examples of exploits against TZ stacks [1]. [1] https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Attacking-Your-Trusted-Core-Exploiting-Trustzone-On-Android-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Att...

yayana 9y ago

It sounds like you are saying Nexus devices have a hsm separate from their gsm card for hardware protected keys, do all fingerprint enabled Android devices have this?

ndesaulniers 9y ago
I'm not sure what hsm/gsm stand for. I can only speak for the Android devices I work on.
- jlgaddis 9y ago
  HSM: https://en.wikipedia.org/wiki/Hardware_security_module https://en.wikipedia.org/wiki/Hardware_security_module GSM: https://en.wikipedia.org/wiki/GSM https://en.wikipedia.org/wiki/GSM
  - microcolonel 9y ago
    By GSM you mean the baseband processor, or what?
    - yayana 9y ago
      Every standard (GSM network) phone has a Sim card that is doing some encryption with hardware protected keys. A Sim card for the GSM network. Trying to use it for general encryption might have problems and is more often discussed than done.
      - microcolonel 9y ago
        Ahh, just say SIM. GSM is the network, SIM is the module. SIMs are basically just javacards, so having custom crypto applications on them is no big deal, but you need some control of the SIMs your users will want to use in your device for it to be practical.
        yayana 9y ago
        Google is US focused so they presumably still deal with non GSM networks and the possibility of running a fingerprint without a gsm standard SIM. * I.e. there are a lot of issues for Google generalizing encryption via some user provided sim as datails come up. So maybe he is referring to an entirely different crypto module.

gumby 9y ago

First of all, I understand your taking offense (though none was intended) since this is the thing you work on. I feel the same way about stuff I work on! Second, I simply used that as a straightforward example, not to say "Apple good, android bad." Security is always a risk tradeoff. My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys. The house is made of glass so someone could just use a brick to get in. For someone else this is a dumb tradeoff; for me it is appropriate. And your message includes an example of such a tradeoff: >This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor). >Somehow implying that Android is less somehow less secure in the case of fingerprint is disingenuous. The channel between the two separate devices is an attack surface (as is the opportunity for offline attack on the encrypted data in the filesystem). The Android team has made the determination that that's an acceptable risk. I won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously less secure than the single, all-encompassing approach. To claim so is hardly disingenuous. Of course, as with my house, this just changes the class of attack. On either platforms you can consider attacking whatever authentication module talks to the TEE. Both systems use other mechanisms for that. Finally, in the Android case a vendor is free to do what they want, especially if they don't care about access to branding, google services etc. Google branded devices have a more important brand to defend than, say, Asus (not to pick on Asus), much less, say, DJI's drones, for which the Android branding is utterly irrelevant (conceivably that could rebound on Google though personally I doubt it would even happen. The same obviously can't be said about iOS :-)

ndesaulniers 9y ago
Those are all fair points, I don't disagree. Maybe disingenuous was the wrong word?
- gumby 9y ago
  It is completely the wrong word since it describes me to be, at best, deceptive. If you don't disagree you can hardly describe claim I was lying!

criddell 9y ago

> keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor) Why is that?

ndesaulniers 9y ago
We don't make our own SoC or Fingerprint Sensor, and time to market.

throwaway25869 9y ago

> They're encrypted with keys that remain in hardware. You can never read the keys, only encrypt files with them, from applications running in a separate physical address space, accessible only through the hypervisor. By 'in hardware', I'm guessing you don't mean real silicon / flash, but rather whatever persistent storage is provided by the SoC vendor's TrustZone implementation. In my opinion calling that 'hardware' implies a level of security and verification that is not actually present, and is disingenuous. If history has shown us anything, it's that relying on a chipmaker's security assurances for platform software features can only end in tears. You don't need to look very far to find real world examples of exploits against TZ stacks [1]. [1] https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Attacking-Your-Trusted-Core-Exploiting-Trustzone-On-Android-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Att...