The killer thing is the performance penalty for doing FHE on any dataset of meaningful size. This is because if you want to do an operation on one member of the set you need to do an operation on all members of the set otherwise you leak which member you care about. For sets of a very small size this performance penalty might be ok. For sets of a large size, like the set of all users of a service, the performance penalty will grow at least linearly to the size of the set.
This is the problem at the core of ZK-style proving systems. You can push the proof construction work into the client and have a sub-linear verification time relative to the proof, but the proof construction in the first place is going to be slow and expensive (and slower as the size of the set increases!).
The edge of research here is being done by cryptography labs all around the world. If someone does manage to solve this in a purely-software based manner with a performance penalty that is acceptable for a monotonically increasing set, that’s the holy grail. I remain unconvinced that this will be solved in a reasonable fashion for this use case in my lifetime (but I would be thrilled to be proven wrong!!). If you know of research which makes inroads on this problem, please point me at it.
Currently it's a wet dream for a lot of businesses.
Note: I work on a system design that I believe is acceptable that uses Intel’s SGX which we detail in this tech talk entitled “why sgx”: youtube.com/watch?v=Hwf_Q31woLo&utm .
In all of the use cases you have mentioned, FHE machine on the user device, can not perform interactions(IO, etc..) with the outside world (can't connect to a network, can't display things on a screen, etc..) without the key. So for these devices to be useful, the keys will have to be embedded in the IO paths(in which case the device would be hackable) or FHE machine should be implemented as subsystem that does things like DRM(I'm not sure if this would be possible either, but it could be).
I might be completely wrong here, but can someone sketch out how FHE can be used to make an unhackable consumer device?
I'm not sure I understand the question, but to me FHE is purely computational thing - only CPU and RAM are involved, and also operations include input and output data. To prevent the system from learning anything about the data, all operations are of kind
(RAM, encrypted output) = FHE(RAM, encrypted input)
so all data in RAM get there in the encrypted form in the first place. Thus the FHE system never see unencrypted data.
Coming back to an unhackable consumer device - if you measure a physical property, like temperature, or have a digital model of anything - you have to provide this data to FHE system only in the properly encrypted form. That encryption is on the consumer, not on FHE, as well as decryption of results of FHE operations. It's only the processing of data which FHE does.
I'm also seeing some questions over side channel attacks by throwing enough data at the polynomial transforms that make up the NAND gate you're hiding the FHE'd data in, some people are claiming there has to be a way to eventually derive the encrypted value of the data you're attacking, but I don't understand any of the maths around FHE so I can't tell how big a concern those types of attacks are. From my layman's interpretation of the comments IBM'ers are responding to, I don't think a single operation under FHE is intrinsically vulnerable to side channel attacks, but I bet how FHE is used in real-world applications with iterative back-and-forth operations does potentially open up specific poorly-designed usage patterns to the classic inferential side channel attacks.
If FHE becomes practical at the scale you imagine, it would dramatically raise the bar on hacking for sure, but the implementers still only need to make one mistake to give a wedge to the hackers to work with.
The tokenization market (tokenize/detokenize sensitive data) just turned up the "interesting" knob to 11, though. Would take a lot of work between vendors to make real and practical, but some real promise there.
What I hoped for is that FHE would usher in the era of more end-user control over the data, not less off it. That's because it would allow to decouple and isolate storage from compute, in such a way that I could invite company's code to process my data, encrypted by me, at the location of my choosing, and the code would have no way to exfiltrate the data. At the same time, I would have no way to get at the service company's software. I somehow never realized it would be easier for software providers to just skip the "my data at my location" part, and just force us to use their FHE software while also owning the data entered into it.
I'm of the understanding that you send me ciphertext, I transform it with some operations you define, and I send back ciphertext-v2.
I can discern how this could exfiltrate data safely. They send in a bunch of zeros and I fill in a one for each minute I used this lightbulb, by dynamically creating the FHE circuit to reflect the data saved.
It's not clear to me how this could change my lightbulb. By 'change' I mean 'affect the behavior' or update the firmware or something. I say this with the expectation that the blobs I received and produced are ciphertext on my side, without keys to decrypt it (unlike, say, dvd drm).
And locally unreadable.
Unless the key is kept locally, which would be hackable.
That's because FHE-encrypted software is locally unhackable as long as its implementation of FHE remains unbroken.
Think:
* FHE-encrypted mobile operating systems, applications, and data.
* FHE-encrypted desktop and server operating systems, applications, and data.
* FHE-encrypted "smart home" devices -- from light bulbs to dishwashers to fridges.
* FHE-encrypted transportation infrastructure -- from automobiles to trains to airplanes.
* FHE-encrypted industrial machinery of all kinds.
If FHE ever becomes practical, we're looking at a very unhackable future.
Remarkably, I've never seen this issue mentioned anywhere else before.