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

51–60 of 124 posts

Re: Security research on Private Cloud Compute

#51

Post by dboreham »

kfreds wrote: post #17

I've been working on technology like this for the past six years. The benefits of transparent systems are likely considerable. The combination of reproducible builds, remote attestation and transparency logging allows trivial detection of a range of supply chain attacks. It can allow users to retroactively audit the source code of remote running systems. Yes, there are attacks that the threat model doesn't protect ag…

I've also worked in this field but it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over.

Re: Security research on Private Cloud Compute

#52

Post by dboreham »

rvnx wrote: post #11
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…

Concrete example of such backdoors: https://www.bloomberg.com/news/features/2018-10-04/the-big-h... The system is protecting you against Apple employees, but not against law enforcement. No matter how much layer of technology you put, at the end of the day, the US companies have to respect the law of the US. The requests can be routed to specific investigation / debugging / beta nodes. Just to turn-on a flag on speci…

The threat is real but that article is disinformation.

Re: Security research on Private Cloud Compute

#53

Post by astrange »

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…

Transparency through things like attestation is capable of proving nothing unexpected is running; for instance you can provide power/CPU time numbers or hashes of arbitrary memory and this can make it arbitrarily hard to run extra code since it would take more time.

And the secure routing does make most of these attacks infeasible.

Re: Security research on Private Cloud Compute

#54

Post by astrange »

rvnx wrote: post #11
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…

Concrete example of such backdoors: https://www.bloomberg.com/news/features/2018-10-04/the-big-h... The system is protecting you against Apple employees, but not against law enforcement. No matter how much layer of technology you put, at the end of the day, the US companies have to respect the law of the US. The requests can be routed to specific investigation / debugging / beta nodes. Just to turn-on a flag on speci…

That article is literally completely made up and didn't happen.

> The requests can be routed to specific investigation / debugging / beta nodes.

No, this is not possible with the design of PCC; they can't control how your requests are routed and there cannot be nodes with extra debugging.

Re: Security research on Private Cloud Compute

#55

Post by astrange »

layer8 wrote: post #43
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…

With virtualized hardware the backdoor doesn’t even strictly need to be in silicon.

That's detectable through timing measurements, for the same reason you can't have data-dependent operations in cryptography.

Re: Security research on Private Cloud Compute

#56

Post by astrange »

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…

> There is absolutely no way for a customer to verify their claims that the data is not saved or transferred elsewhere.

Transparency logs are capable of verifying that, it's more or less the whole point of them. (Strictly speaking, you can make it arbitrarily expensive to fake it.)

Also, if they were "transferring your data elsewhere" it would be a GDPR violation. Ironically wrt your China claim, it would also be illegal in China, which does in fact have privacy laws.

Re: Security research on Private Cloud Compute

#57

Post by saagarjha »

astrange wrote: post #55
layer8 wrote: post #43

Earlier quoted context omitted.

With virtualized hardware the backdoor doesn’t even strictly need to be in silicon.

That's detectable through timing measurements, for the same reason you can't have data-dependent operations in cryptography.

Ok, where are the timing measurements?

Re: Security research on Private Cloud Compute

#58

Post by bitexploder »

kfreds wrote: post #17

I've been working on technology like this for the past six years. The benefits of transparent systems are likely considerable. The combination of reproducible builds, remote attestation and transparency logging allows trivial detection of a range of supply chain attacks. It can allow users to retroactively audit the source code of remote running systems. Yes, there are attacks that the threat model doesn't protect ag…

The xz backdoor would have been a yawn instead the many hands fire drill it was at most big orgs. It was scary.

Re: Security research on Private Cloud Compute

#59

Post by bitexploder »

dboreham wrote: post #51
kfreds wrote: post #17

I've been working on technology like this for the past six years. The benefits of transparent systems are likely considerable. The combination of reproducible builds, remote attestation and transparency logging allows trivial detection of a range of supply chain attacks. It can allow users to retroactively audit the source code of remote running systems. Yes, there are attacks that the threat model doesn't protect ag…

I've also worked in this field but it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over.

Each layer needs more than one safeguard then. If breaking the layer breaks the system then the layer needs better safe guards.

Re: Security research on Private Cloud Compute

#60

Post by yalogin »

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…

No, you trust the HW and so starting with secure boot you can get measurements cryptographically vouched for. That you can prove and verify.

So at some point you have no option but to trust something/someone

Post reply on HN