3 ms·

Worked on this precise root of trust problem some years ago. Basic issue is, fragmentation in the device marketplace means you can't have an endogenous hardwar

Worked on this precise root of trust problem some years ago. Basic issue is, fragmentation in the device marketplace means you can't have an endogenous hardware root of trust on each device. Apple can do this because they own the whole device stack. Providing this outside that closed ecosystem will have hard limits foreseeably. That said, the only tech I am aware of that could conceivably change the balance of this device fragmentation equation is FHE that is sophisticated enough to perform nested standard encryption operations for authentication. Otherwise, your options are a separate yubikey-like token that you buy and "personalize," with new keys and linking identity attributes to it, or some weak variation of obfuscated code to store and process your root of trust key. Business wise, the threat model has a catastrophic failure mode, where a compromise likely exposes all users simultaneously, which becomes both worse and more likely as you scale. Then there are the use cases for strong identity proofing and authentication, where they all reduce to some powerful party wanting someone else to adopt sufficiently strong identity to use as recourse against them. Strong identity is for institutions to manage populations interchangeably, and nobody signs up for that, it's regulated down onto them. The conceptual test I use is, if it interferes with your ability to consume drugs or pornography, it's not a viable consumer product. Strong identity proofing without commensurately strong anonymity fails that heuristic. Self sovereign identity is only viable if it's either anonymous and disposable, or enforced downwards by a de-facto monopoly. When I looked at the related startup company's site, I thought, "clearly the VC investment triad decision was based on 'team+market', with 'product' to be figured out later." I'm definitely not smarter than anyone involved there, but the product hurdles in front of them are expensive, political, and complex.

lifeisstillgood 6y ago
I may be very dumb but are you suggesting that Fully Homomorphic encryption (FHE) could perform client authentication in the cloud? Is it possible that I FHE-wrap my own private key, send it to you, and you can sign with my key without the plain text? that sounds crazy? Am I missing something?
- motohagiography 6y ago
  The reason I suggested FHE might change this was the a few of the solutions people have tried so far fall into the so-called "white box cryptography," bucket of key based obfuscators on your mobile/endpoint device. Depending on the authentication scheme or security protocol, you need a secure place to store your private key, a shared or derived secret, key encryption keys, or a certificate, etc. We have to assume that the OS of that client device is going to get rooted at some point and the security of those keys is gone - and with it, the identity assurance they provided. (again, the secure element and diversified initialization keys on apple devices is different, think of it as a little client side hsm) Instead of using WBC, in this hypothetical case FHE becomes the scheme for performing a verification step without yielding information about the key to an attacker with root on the device. It's another handwavey blackbox, but it's a such a change in how we do security protocols that it's worth mentioning as plausibly having consequences for authN. It's a hard problem that gets addressed in areas like authenticated encryption, direct anonymous attestation, and other more use case specific protocols. Someone working in the field today would have more insight into it.
  - lifeisstillgood 6y ago
    Hmm, I was asking as a few days back the IBM FHE release provoked me to ask what were the use cases for FHE? This seems to be, tantalisingly, the most interesting so far.
    - motohagiography 6y ago
      If FHE has a practical internal xor operation, the idea of iterating a key and diversification component/counter, e.g. like a FHE implementation of HOTP or OCRA becomes really interesting. Even if it's slow, you could probably stack the slow operations into the initialization/personalization phases. Security and authN protocols are really just about using crypto to diffuse and distribute risk, so it's conceivable there are use cases where FHE facilitates shifting risk for key security onto the end user, like payment cards, etc.
raxxorrax 6y ago
> Otherwise, your options are a separate yubikey-like token that you buy and "personalize" These "burner phone"-keys are perhaps preferable to many people. > you can't have an endogenous hardware root of trust on each device You mean practically transferable? Sadly, a lot of security applications currently link their functionality to specific phone hardware. I think the whole approach to declare your device compromised just doesn't really fit practical applications but has become a pretty common axiom, although I understand the pessimism if we look at OS for mobile devices. Why would I believe trusted computing hardware and not the software in times we change both frequently? Doesn't really ring a bell for me. And beyond that I don't like to be treated as a terrorist by my own machine. I fully agree that an identity should be at least disposable and certainly as anonymous as it can be. This are the core requirements I would level at a solution.
deleted 6y ago
[deleted]

lifeisstillgood 6y ago

I may be very dumb but are you suggesting that Fully Homomorphic encryption (FHE) could perform client authentication in the cloud? Is it possible that I FHE-wrap my own private key, send it to you, and you can sign with my key without the plain text? that sounds crazy? Am I missing something?

motohagiography 6y ago
The reason I suggested FHE might change this was the a few of the solutions people have tried so far fall into the so-called "white box cryptography," bucket of key based obfuscators on your mobile/endpoint device. Depending on the authentication scheme or security protocol, you need a secure place to store your private key, a shared or derived secret, key encryption keys, or a certificate, etc. We have to assume that the OS of that client device is going to get rooted at some point and the security of those keys is gone - and with it, the identity assurance they provided. (again, the secure element and diversified initialization keys on apple devices is different, think of it as a little client side hsm) Instead of using WBC, in this hypothetical case FHE becomes the scheme for performing a verification step without yielding information about the key to an attacker with root on the device. It's another handwavey blackbox, but it's a such a change in how we do security protocols that it's worth mentioning as plausibly having consequences for authN. It's a hard problem that gets addressed in areas like authenticated encryption, direct anonymous attestation, and other more use case specific protocols. Someone working in the field today would have more insight into it.
- lifeisstillgood 6y ago
  Hmm, I was asking as a few days back the IBM FHE release provoked me to ask what were the use cases for FHE? This seems to be, tantalisingly, the most interesting so far.
  - motohagiography 6y ago
    If FHE has a practical internal xor operation, the idea of iterating a key and diversification component/counter, e.g. like a FHE implementation of HOTP or OCRA becomes really interesting. Even if it's slow, you could probably stack the slow operations into the initialization/personalization phases. Security and authN protocols are really just about using crypto to diffuse and distribute risk, so it's conceivable there are use cases where FHE facilitates shifting risk for key security onto the end user, like payment cards, etc.

raxxorrax 6y ago

> Otherwise, your options are a separate yubikey-like token that you buy and "personalize" These "burner phone"-keys are perhaps preferable to many people. > you can't have an endogenous hardware root of trust on each device You mean practically transferable? Sadly, a lot of security applications currently link their functionality to specific phone hardware. I think the whole approach to declare your device compromised just doesn't really fit practical applications but has become a pretty common axiom, although I understand the pessimism if we look at OS for mobile devices. Why would I believe trusted computing hardware and not the software in times we change both frequently? Doesn't really ring a bell for me. And beyond that I don't like to be treated as a terrorist by my own machine. I fully agree that an identity should be at least disposable and certainly as anonymous as it can be. This are the core requirements I would level at a solution.

deleted 6y ago

[deleted]