Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security research on Private Cloud Compute

security.apple.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: Security research on Private Cloud Compute

#31

Post by kfreds »

formerly_proven wrote: post #24
kfreds wrote: post #21

Earlier quoted context omitted.

> I feel like this is all smoke and mirrors to redirect from the likelihood intentional silicon backdoors that are effectively undetectable. The technologies Apple PCC is using has real benefits and is most certainly not "all smoke and mirrors". Reproducible builds, remote attestation and transparency logging are individually useful, and the combination of them even more so. As for the likelihood of Apple launching A…

Apple forgot to disable some cache debugging registers a while back which in effect was similar to something GP described, although exploitation required root privileges and would allow circumventing their in-kernel protections; protections most other systems do not have. (And they still didn't manage to achieve persistence, despite having beyond-root privileges).

> Apple forgot to disable some cache debugging registers a while back which in effect was similar to something GP described

Thank you for bringing that up. Yes, it is an excellent example that proves the existence of silicon vulnerabilities that allow privilege escalation. Who knows whether it was left there intentionally or not, and if so by whom.

I was primarily arguing that (1) the technologies of Apple PCC are useful and (2) it is _very_ unlikely that Apple PCC is a ploy by Apple, to direct attention away from backdoors in the silicon.

Re: Security research on Private Cloud Compute

#32

Post by dewey »

danielhep wrote: post #22
dewey wrote: post #2

Looks like they are really writing everything in Swift on the server side. Repo: https://github.com/apple/security-pcc

Is using something other than XCode viable? I'd love to do more with swift but I hate that IDE.

Most editors will do, Xcode is mostly needed for iOS / macOS development if you want to submit to the App Store or work with a lot of Apple frameworks.

Re: Security research on Private Cloud Compute

#33

Post by warkdarrior »

kfreds wrote: post #26
dented42 wrote: post #15

Earlier quoted context omitted.

This is my thought exactly. I really love the idea of open hardware, but I don’t see how it would protect against cover surveillance. What’s stopping a company/government/etc from adding surveillance to an open design? How would you determine that the hardware being used is identical to the open hardware design? You still ultimately have to trust that the organisations involved in manufacturing/assembling/installing/…

> How would you determine that the hardware being used is identical to the open hardware design? FPGAs can help with this. They allow you to inspect the HDL, synthesize it and configure it onto the FPGA chip yourself. The FPGA chip is still proprietary, but by using an FPGA you are making certain supply chain attacks harder.

How do you know the proprietary part of the FPGA chip performs as expected and does not covertly gather data from the configured gates?

Re: Security research on Private Cloud Compute

#34

Post by brokenmachine »

mmastrac wrote: post #5

I feel like this is all smoke and mirrors to redirect from the likelihood intentional silicon backdoors that are effectively undetectable. Without open silicon, there's no way to detect that -- say -- when registers r0-rN are set to values [A, ..., N] and a jump to address 0xCONSTANT occurs, additional access is granted to a monitor process. Of course, this limits the potential attackers to 1) exactly one government…

Relevant:

37C3 - Operation Triangulation: What You Get When Attack iPhones of Researchers https://www.youtube.com/watch?v=1f6YyH62jFE

Absolutely insane attack. Really opens your eyes on what nation-state attackers are capable of.

Re: Security research on Private Cloud Compute

#35

Post by iforgotmysocks »

danielhep wrote: post #22
dewey wrote: post #2

Looks like they are really writing everything in Swift on the server side. Repo: https://github.com/apple/security-pcc

Is using something other than XCode viable? I'd love to do more with swift but I hate that IDE.

There is a Swift LSP. See - https://github.com/swiftlang/sourcekit-lsp

Re: Security research on Private Cloud Compute

#36

Post by kmeisthax »

mmastrac wrote: post #5

I feel like this is all smoke and mirrors to redirect from the likelihood intentional silicon backdoors that are effectively undetectable. Without open silicon, there's no way to detect that -- say -- when registers r0-rN are set to values [A, ..., N] and a jump to address 0xCONSTANT occurs, additional access is granted to a monitor process. Of course, this limits the potential attackers to 1) exactly one government…

The economics of silicon manufacturing and Apple's own security goals (including the security of their business model) restrict the kinds of backdoors you can embed in their servers at that level.

Let's assume Apple has been compromised in some way and releases new chips with a backdoor. It's expensive to insert extra logic into just one particular spin of a chip; that involves extra tooling cost that would be noticeable line-items and show up in discovery were Apple to be sued about their false claims. So it needs to be on all the chips, not just a specific "defeat PCC" spin of their silicon. So they'd be shipping iPads and iPhones with hardware backdoors.

What happens when those backdoors inevitably leak? Well, now you have a trivial jailbreak vector that Apple can't patch. Apple's security model could be roughly boiled down as "our DRM is your security"; while they also have lots of actual security, they pride themselves on the fact that they have an economic incentive to lock the system down to keep both bad actors and competing app stores out. So if this backdoor was inserted without the knowledge of Apple management, there are going to be heads rolling. And if it was, then they're going to be sued up the ass once people realize the implications of such a thing, because Tim Cook went up on stage and promised everyone they were building servers that would refuse to let them read your Siri queries.

Re: Security research on Private Cloud Compute

#37

Post by kfreds »

warkdarrior wrote: post #33
kfreds wrote: post #26

Earlier quoted context omitted.

> How would you determine that the hardware being used is identical to the open hardware design? FPGAs can help with this. They allow you to inspect the HDL, synthesize it and configure it onto the FPGA chip yourself. The FPGA chip is still proprietary, but by using an FPGA you are making certain supply chain attacks harder.

How do you know the proprietary part of the FPGA chip performs as expected and does not covertly gather data from the configured gates?

> How do you know the proprietary part of the FPGA chip performs as expected and does not covertly gather data from the configured gates?

We don't, but using an FPGA can make supply chain attacks harder.

Let's assume you have a chip design for a microcontroller and you do a tapeout, i.e. you have chips made. An attacker in your supply chain might attack your chip design before the design makes it to the fab, maybe the attacker is at the fab, or they change out the chips after you've placed them on your PCB.

If you use an FPGA, your customer could stress test the chip by configuring a variety of designs onto the FPGA. These designs should stress test timing, compute and memory at the very least. This requires the attacker's chip to perform at least as well as the FPGA you're using, while still having the same footprint. An attacker might stack the real FPGA die on top of the attacker's die, but such an attack is much easier to detect than a few malicious gates on a die. As for covertly gathering or manipulating data, on an FPGA you can choose where to place your cores. That makes it harder for the attacker to predict where on the FPGA substrate they should place probes, or which gates to attack in order to attack your TRNG, or your master key memory. Those are just some examples.

If you're curious about this type of technology or line of thinking you can check out the website of one of my companies: tillitis.se

Re: Security research on Private Cloud Compute

#38

Post by threeseed »

mmastrac wrote: post #5

I feel like this is all smoke and mirrors to redirect from the likelihood intentional silicon backdoors that are effectively undetectable. Without open silicon, there's no way to detect that -- say -- when registers r0-rN are set to values [A, ..., N] and a jump to address 0xCONSTANT occurs, additional access is granted to a monitor process. Of course, this limits the potential attackers to 1) exactly one government…

You have to be serious here.

The level of conspiracy needed to keep something like this a secret would be unprecedented.

And if Apple was able to do that why wouldn't they just backdoor iOS/OSX instead of baking it into the hardware.

Re: Security research on Private Cloud Compute

#39

Post by threeseed »

kfreds wrote: post #25
yalogin wrote: post #6

Earlier quoted context omitted.

This is an interesting idea. However what does open hardware mean? How can you prove that the design or architecture that was “opened” is actually what was built? What does the attestation even mean in this scenario?

> what does open hardware mean? Great question. Most hardware projects I've seen that market themselves as open source hardware provide the schematic and PCB design, but still use ICs that are proprietary. One of my companies, Tillitis, uses an FPGA as the main IC, and we provide the hardware design configured on the FPGA. Still, the FPGA itself is proprietary. Another aspect to consider is whether you can audit and…

And what attestation do you have that the FPGA isn't compromised.

We can play this game all the way down.

Re: Security research on Private Cloud Compute

#40

Post by kfreds »

gigel82 wrote: post #29

No amount of remote attestation and "transparency logs" and other bombastic statements like this would make up for the fact that they are fully in control of the servers and the software. There is absolutely no way for a customer to verify their claims that the data is not saved or transferred elsewhere. So unless they offer a way for us to run the "cloud services" on our own hardware where we can strictly monitor an…

> No amount of remote attestation and "transparency logs" and other bombastic statements like this would make up for the fact that they are fully in control of the servers and the software. There is absolutely no way for a customer to verify their claims that the data is not saved or transferred elsewhere.

You are right. Apple is fully in control of the servers and the software, and there is no way for a customer to verify Apple's claims. Nevertheless system transparency is a useful concept. It can effectively reduce the number of things you have to blindly trust to a short and explicit list. Conversely it forces the operator, in this case Apple, to explicitly lie. As others have pointed out, that is quite a business risk.

As for transparency logs, it is an amazing technology which I can highly recommend you take a look at in case you don't know what it is or how it works. Check out transparency.dev or the project I'm involved in, sigsum.org.

> they are almost guaranteed to be misusing that data

That is very unlikely because of the liability, as others have pointed out. They are making claims which the Apple PCC architecture helps make falsifiable.

Post reply on HN