7 ms·

Fully homomorphic encryption (FHE) looks to me like the WET DREAM of every business that wants to control the software and content on your hardware without ever

by cs702 6y ago

Fully homomorphic encryption (FHE) looks to me like the WET DREAM of every business that wants to control the software and content on your hardware without ever having to decrypt sensitive code or data residing on that hardware. 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.

dplgk 6y ago
How does that work? If the business can control it, then it's hackable.
- tyingq 6y ago
  I read it as "locally unhackable". Any hack would have to hit the mother ship.
  - cs702 6y ago
    Yes, exactly. FYI, I added the word "locally" to my parent comment above to make the meaning clearer.
  - worewood 6y ago
    As I understand it, in order to interface with a FH-encrypted software the data needs to be encrypted too. So every input needs to be sent to the mothership, encrypted there, downloaded, then computed locally, then the output is sent to the mothership, decrypted, then downloaded to present the results to the user -- which is no different than just doing the computation "in the cloud", which already is a thing. So I don't see how it brings anything new to the table. Unless the key is kept locally, which would be hackable.
    - nyolfen 6y ago
      there is a pretty big difference between having to hack a local key for every user and a real data breach
    - tyingq 6y ago
      Maybe more applicable for something like DRM?
    - benlivengood 6y ago
      FHE operates under asymmetrical encryption and the one running the software needs the public key to perform the FHE operations on the data. The private key is known to the manufacturer (although there are some cool applications if no one knows the private key, provably) and is part of the logical circuit of the FHE so that it can decrypt and freshen it's state.
yourapostasy 6y ago
The part where FHE requires 42X cpu and 10-20X RAM of non-FHE operations will initially keep the use cases relatively small, and we don't have Moore's progression to bail them out in a few years. Neither are FHE operations in these kinds of use cases heavily parallelizable. 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.
josh2600 6y ago
FHE gets brought up all the time. There are great discussions down thread about why this isn’t practical for most use cases. 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.
- cs702 6y ago
  Agree. That's why I wrote, "If FHE ever becomes practical..." -- because at present it isn't. Currently it's a wet dream for a lot of businesses.
  - josh2600 6y ago
    FHE style systems are possible if you use a hardware-based encryption approach like a Secure Enclave, but then you have a trust narrative that includes a Secure Enclave. For most use cases this is unacceptable. 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 .
    - ezVoodoo 6y ago
      If you believe in a Secure Enclave then there is no need for Fully Homomorphic Encryption anymore as all the computation can be carried securely in the SE. The question is the SE is not trustable for many people.
Nzen 6y ago
I agree this is a novel interpretation. Could you elaborate on what the computation performed involves ? 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).
mr_toad 6y ago
> That's because FHE-encrypted software is locally unhackable And locally unreadable.
madushan1000 6y ago
I'm not sure if FHE is valid for any of these use cases, as far as I can understand, FHE machines/evaluators can operate on encrypted data, but can not derive any useful information from that data without the key. 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?
- avmich 6y ago
  The original - unencrypted - data from a user, or sensor, pass through encryption layer before going to FHE system. 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.
TeMPOraL 6y ago
Huh. Never thought about it from that point of view, thanks for bringing it up. 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.
JoshuaDavid 6y ago
I think the use cases of FHE are much more limited that you're thinking, specifically because it allows you to execute code on someone else's machine without them being able to see _anything_ about the data they're operating on, and send the results (which again, don't mean anything to that machine) back to you. So, for example, you could mine cryptocurrency on someone's computer, but the only benefit you get over running FHE-encrypted code on the client machine over running it on your own server is compute cost. It wouldn't be useful for e.g. DRM.
totetsu 6y ago
Basically Ransomeware

by cs702 6y ago

dplgk 6y ago

How does that work? If the business can control it, then it's hackable.

tyingq 6y ago
I read it as "locally unhackable". Any hack would have to hit the mother ship.
- cs702 6y ago
  Yes, exactly. FYI, I added the word "locally" to my parent comment above to make the meaning clearer.
- worewood 6y ago
  As I understand it, in order to interface with a FH-encrypted software the data needs to be encrypted too. So every input needs to be sent to the mothership, encrypted there, downloaded, then computed locally, then the output is sent to the mothership, decrypted, then downloaded to present the results to the user -- which is no different than just doing the computation "in the cloud", which already is a thing. So I don't see how it brings anything new to the table. Unless the key is kept locally, which would be hackable.
  - nyolfen 6y ago
    there is a pretty big difference between having to hack a local key for every user and a real data breach
  - tyingq 6y ago
    Maybe more applicable for something like DRM?
  - benlivengood 6y ago
    FHE operates under asymmetrical encryption and the one running the software needs the public key to perform the FHE operations on the data. The private key is known to the manufacturer (although there are some cool applications if no one knows the private key, provably) and is part of the logical circuit of the FHE so that it can decrypt and freshen it's state.

yourapostasy 6y ago

The part where FHE requires 42X cpu and 10-20X RAM of non-FHE operations will initially keep the use cases relatively small, and we don't have Moore's progression to bail them out in a few years. Neither are FHE operations in these kinds of use cases heavily parallelizable. 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.

josh2600 6y ago

FHE gets brought up all the time. There are great discussions down thread about why this isn’t practical for most use cases. 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.

cs702 6y ago
Agree. That's why I wrote, "If FHE ever becomes practical..." -- because at present it isn't. Currently it's a wet dream for a lot of businesses.
- josh2600 6y ago
  FHE style systems are possible if you use a hardware-based encryption approach like a Secure Enclave, but then you have a trust narrative that includes a Secure Enclave. For most use cases this is unacceptable. 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 .
  - ezVoodoo 6y ago
    If you believe in a Secure Enclave then there is no need for Fully Homomorphic Encryption anymore as all the computation can be carried securely in the SE. The question is the SE is not trustable for many people.

Nzen 6y ago

I agree this is a novel interpretation. Could you elaborate on what the computation performed involves ? 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).

mr_toad 6y ago

> That's because FHE-encrypted software is locally unhackable And locally unreadable.

madushan1000 6y ago

I'm not sure if FHE is valid for any of these use cases, as far as I can understand, FHE machines/evaluators can operate on encrypted data, but can not derive any useful information from that data without the key. 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?

avmich 6y ago
The original - unencrypted - data from a user, or sensor, pass through encryption layer before going to FHE system. 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.

TeMPOraL 6y ago

Huh. Never thought about it from that point of view, thanks for bringing it up. 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.

JoshuaDavid 6y ago

I think the use cases of FHE are much more limited that you're thinking, specifically because it allows you to execute code on someone else's machine without them being able to see _anything_ about the data they're operating on, and send the results (which again, don't mean anything to that machine) back to you. So, for example, you could mine cryptocurrency on someone's computer, but the only benefit you get over running FHE-encrypted code on the client machine over running it on your own server is compute cost. It wouldn't be useful for e.g. DRM.

totetsu 6y ago

Basically Ransomeware