91–100 of 124 posts
That to me is the innovation here, everything else is just standard bits.
I haven't had time to dig through the splunklogger, but I had hoped that logging was mostly disabled and you could only emit metrics. That was my reading of the PCC manifesto.
Earlier quoted context omitted.
> they can choose to emit whatever logs they want into the "transparent logs" and then emit whatever else they don't want into non-transparent logs. The log is publicly accessible and append-only, so such an event would not go un-noticed. Not sure what a non-transparent log is.
Ok, but they write and fully control the closed-source software that appends to the log. How can anyone verify that all the code paths append to the log? I'm pretty sure they can just not append to the log from their ExfiltrateDataForAdvertisment() and ExfiltrateDataForGovernments() functions. Maybe I'm not being clear; transparent logs solve the problem of supply chain attacks (that is, Apple can use the logs to som…
davidczech has already explained it quite well, but I'll try explaining it a different way.
Consider the verification of a signed software update. The verifier, e.g. apt-get, rpm, macOS Update, Microsoft Update or whatever OS you're running. They all have some trust policy that contains a public key. The verifier only trusts software signed by the public key.
Now imagine a verifier with a trust policy that mandates that all signed software must also be discoverable in a transparency log. Such a trust policy would need to include:
- a pubkey trusted to make the claim "I am your trusted software publisher and this software is authentic", i.e. it is from Debian / Apple / Microsoft or whomever is the software publisher.
- a pubkey trusted to make the claim "I am your trusted transparency log and this software, or rather the publisher's signature, has been included in my log and is therefore discoverable"
The verifier would therefore require the following in order to trust a software update:
- the software (and its hash) - a signature over the software's hash, done by the software publisher's key - an inclusion proof from the transparency log
There is another layer that could be added called witness cosigning, which reduces the amount of trust you need to place in the transparency log. For more on that see my other comments in this thread.
For example, https://github.com/search?q=repo%3Aapple%2Fsecurity-pcc%20rd..., lists out all references to `rdar` which is a link schema for Apple's bug management system.
Also, it is clear that the code is cross platform (it references iOS and macOS). So the code here gives clues as to the security operation of iOS as well in case you wanted to do iOS security research.
It is lovely to see the middleware here written in Swift. It is quite chunky. Reading all that XPC code gives me the shivers (as I've personal experience with how tricky that can get).
Overall it is a very interesting offering. I wish I had two weeks to burn through the details... [I am the author of The Road to Zero, and iOS Crash Dump Analysis].
Earlier quoted context omitted.
Unfortunately that's not the case. All remote attestation technology is rooted by a PKI (the DCA certificate authority in this case). There's some data somewhere that simply asserts that a particular key was generated inside a CPU, and everything is chained off that. There's currently no good way to prove this step so you just have to take it on faith. Forge such an assertion and you can sign statements that device X…
Hi Mike! Long time no see. > simply asserts that a particular key was generated inside a CPU ... There's currently no good way to prove this step Yes, but there are better and worse ways to do it. Here's how I think about it. I know you know some of this but I'll write it out for other HN readers as well. Let's start with the supply chain for an SoC's master key. A master key that only uses entropy from an on-die PUF…
Let's agree that Apple are doing state-of-the-art work in terms of internal manufacturing controls and making those auditable. I think actually the more interesting and tricky part is how to manage software evolution. This is something I've brought up with [potential] customers in the past when working with them on SGX related projects: for this to make sense, socially, then there has to be a third party audit for not only the software in the abstract but each version of the software. And that really needs to be enforced by the client, which means, every change to the software needs to be audited. This is usually a non-starter for most companies because they're afraid it'd kill velocity, so for my own experiments I looked at in-process sandboxing and the like to try and restrict the TCB even within the remotely attested address space.
In this case Apple may have an advantage because the software is "just" doing inferencing, I guess, which isn't likely to be advantageous to keep secret, and inferencing logic is fairly stable, small and inherently sandboxable. It should be easy to get it to be audited. For more general application of confidential/private computing though it's definitely an issue.
The issue of multiple Apple devs conspiring isn't so unlikely in my view. Bear in mind that end-to-end encryption made similar sorts of promises that tech firm employees can't read your messages, but the moment WhatsApp decided that combating "rumors" was the progressive thing to do they added a forwarding counter to messages so they could stop forwarding chains. Cryptography 101: your adversary should not be able to detect that you're repeating yourself; failed, just like that. The more plausible failure mode here is therefore not the case of spies or saboteurs but rather a deliberate weakening of the software boundary to leak data to Apple because executives decide they have a moral duty to do so. This doesn't even necessarily have to be kept secret. WhatsApp's E2E forwarding policy is documented on their website, they announced it in a blog post. My experience is that 99% of even tech workers believe that it does give you normal cryptographic guarantees and is un-censorable as a consequence, which just isn't the case.
Still, all this does lay the foundations for much stronger and more trustworthy systems, even if not every problem is addressed right away.
Earlier quoted context omitted.
If you take as a fundamental assumption that all your hardware is backdoored by Mossad who has unlimited resources and capacity to intercept and process all your traffic, the game is already lost and there’s no point in doing anything. If instead you assume your attackers have limited resources, things like this increase the costs attackers have to spend to compromise targets, reducing the number of viable targets an…
Soviets used typewriters. American Lawyers of the highest pedigree (HNWI) don't even use email. Your hardware is back-doored, as Intel is named "Intel" for a (nearly too poignant) reason.
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…
Looks like they are really writing everything in Swift on the server side. Repo: https://github.com/apple/security-pcc
It's worth keeping in mind that these AI machines run an environment very similar to Mac OS, XNU kernel and all, and are powered by Apple Silicon. Using Swift in that context makes sense. At least according to what we publicly know, no other backend Apple services follow this model.
I have been trying to look for that but I guess it will likely be a bit longer.
Earlier quoted context omitted.
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.
> 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 Interesting. Please elaborate. Here's how I see it. Reproducible builds: I think we'll eventually see Linux distributions like Debian make reproducible builds mandatory by enforcing it in apt-get's trust policy. The trust policy could be expressed as "I will only trust .deb pac…
ironically when talking about losing control of cloud compute.
there is no private other-people-computer, by definition.
what those attempts try to do, is to change the definition.