3 ms·

You're hand-waving past a critical detail when you say "tied to". Signing and encrypting are different processes. Verifying a signature uses the public key, w

You're hand-waving past a critical detail when you say "tied to". Signing and encrypting are different processes. Verifying a signature uses the public key, which everybody has. Decryption uses a secret key, which by definition isn't publicly available. Most of the schemes you're thinking of (Intel SGX, etc) boil down to surrendering control to the CPU manufacturer and trusting them to manage your keys for you, and do the right thing. Even when pressured by nation-states.

saurik 6y ago
So, I realize that many people somehow seem to think it is more correct to not look up who they are speaking with, as if that shouldn't matter; but, I find that as language is ambiguous, and often we are lazy in our speaking or assume "the other person should be able to fill in the gaps I didn't say using what I presume to be common knowledge here", it is actually somewhat important? (To said point, I tried to look up who you were to see if you were likely to somehow know more about this than I do and are just coming off as extra condescending as maybe you merely dislike me, but you don't have a bio and there are multiple Kirill Panovs ;P.) I guess I only have an indirect bio (though I do have a famous username ;P), but I will introduce myself regardless: I am Jay Freeman, aka saurik, the "godfather" (but not quite the "father") of jailbreaking. I have both developed myself and worked with others to develop many tools over the years to break various signed boot mechanisms, for both Android and, notably, iOS. I am certainly not the person I know who knows the most about how these work, and I usually do my iOS attacks further up the stack, but I certainly am not a dilettante here or anything ;P. I definitely at least understand how cryptography works :/ (and I am currently in charge of technology and architecture for a well-funded cryptocurrency project). Additionally, I happen to be a pretty intense public critic of Intel SGX (and so I have some appreciation of why people hate this kind of tech). All I am really saying here for a concrete suggested implementation for how this should work (as I take it this wasn't obvious and you are maybe "curious") is designed around an appreciation of how Apple already handles full disk encryption, so we need to examine whether your "pressured by nation states" attack already works against an iPhone (spoiler alert: it doesn't). Let's say you leave an iPhone on a table, the FBI takes it, and now Apple is required to unlock it (as in the San Bernardino case). I was a big name hitting Apple hard on this: they absolutely could bypass that phone, because they left themselves what amounted to a back door to do firmware upgrades without the user's permission (which was the actual issue at hand, not the "effort" to building a modified firmware image: anyone could have done that if Apple merely signed the result). However, this was fixed: firmware updates of both the OS and (as far as I know) the secure enclave now require the user to unlock the device. This unlock process is protected from brute force by the software running in this secure enclave, and Apple is unable to bypass it even if they are "pressured by nation states". They hadn't implemented this on the older devices, and I felt their stance in that case was thereby disingenuous, but they had already mostly fixed the issue in the subsequent already-released-at-the-time phone and they later fixed it even better. (Now, there are also was an exploit people found in those phones, but that's clearly a different problem.) What I am suggesting for this situation is to start with the iOS secure boot chain behavior but then implement a mechanism similar to the Android "wipe disk on bootloader unlock" solution that itself works similarly to the Android APK upgrade process: when a kernel is presented to the bootloader, instead of it being checked strictly for "is this signed by Apple", it would accept any kernel signed by any key... but instead of merely jumping into the kernel after loading it, it would pass the address of the memory region, the signature, and the entry point (edit: this bit needs to be inside of the signed kernel image) to the secure enclave, which would now verify the signature and jump to the entrypoint (instead of this being done directly by the secure bootloader). Since the secure enclave (which is of course immune to your blue pill attack) is now what verified the signature of the kernel, it would be able to use the hash of the public key of the certificate for the signature of the kernel as part of its key derivation path for subsequent encryption work. This would allow the full disk encryption--which is already being done in the secure enclave (keys are managed there, as you note, but without the issue you claim it has), to avoid the kernel having direct access to the root filesystem keys--to be "tied to" (which I honestly assumed anyone in this kind of discussion would understand immediately ;P) the kernel vendor (which might be the user, if they compile their own kernels: the user absolutely should be allowed to install their own kernels). (FWIW, if you want to blast me for "hand waiving" anything to the point where I imagine someone who works on this stuff wouldn't be able to quickly derive it, it is that I appreciate that kernels are usually stored on filesystems, causing a chicken-and-the-egg issue; but I personally have always found that to be incompetent, as it means that the second stage bootloader on iOS seriously has a full HFS+ filesystem parser, which has in the past been the source of bugs serious enough to cause key leakage :/. Just don't do that... somehow? Maybe do what Android does, with a separate flash partition for the kernel image? I certainly would admit that dealing with this quirk feels like a separate step.) What I like about this kind of scheme is that it makes the bootloader "work for the user" instead of merely working for Apple. It also doesn't leave the user stranded without secure boot if they want to boot their own kernel. I want a scheme where users can choose their own trust root, and that's effectively what this is automatically doing, with the secure enclave feeling more like a secure hardware piece than being relayed to the operating system. (This all said: I haven't looked at all into how the M1 works... the Apple engineers who work on this have shitty motivations and at-best-borderline morality, but they aren't stupid: if they actually got the green light to work on this, for all I know this is how it already operates. I also am only an expert on mobile systems in general, so I have never looked into the schemes developed by Microsoft and Intel... I kind of feel like, by default, they would suck, though :/.) I thereby feel like there is both a way it "should" work--which involves tying the full disk encryption to the key of the kernel vendor--which admittedly might be how it did work; but, either way: I believe that (barring mistakes in the implementation, which sadly almost certainly will exist, and may as well be "back doors" :/) it is at least possible (whether my suggestion was a complaint that Apple did it incorrectly or an accidental explanation for why they did correct) to do this without causing some kind of obvious "blue pill" attack (and yes, it does involve a secure enclave, but I believe the thing Apple does isn't as intrinsically evil as the thing Intel does, as the core problem is third-party attestation, as that is what gives you ridiculous DRM scenarios of your hardware hiding stuff from the user on behalf of the software instead of the other way around).
deleted 6y ago
[deleted]

saurik 6y ago

So, I realize that many people somehow seem to think it is more correct to not look up who they are speaking with, as if that shouldn't matter; but, I find that as language is ambiguous, and often we are lazy in our speaking or assume "the other person should be able to fill in the gaps I didn't say using what I presume to be common knowledge here", it is actually somewhat important? (To said point, I tried to look up who you were to see if you were likely to somehow know more about this than I do and are just coming off as extra condescending as maybe you merely dislike me, but you don't have a bio and there are multiple Kirill Panovs ;P.) I guess I only have an indirect bio (though I do have a famous username ;P), but I will introduce myself regardless: I am Jay Freeman, aka saurik, the "godfather" (but not quite the "father") of jailbreaking. I have both developed myself and worked with others to develop many tools over the years to break various signed boot mechanisms, for both Android and, notably, iOS. I am certainly not the person I know who knows the most about how these work, and I usually do my iOS attacks further up the stack, but I certainly am not a dilettante here or anything ;P. I definitely at least understand how cryptography works :/ (and I am currently in charge of technology and architecture for a well-funded cryptocurrency project). Additionally, I happen to be a pretty intense public critic of Intel SGX (and so I have some appreciation of why people hate this kind of tech). All I am really saying here for a concrete suggested implementation for how this should work (as I take it this wasn't obvious and you are maybe "curious") is designed around an appreciation of how Apple already handles full disk encryption, so we need to examine whether your "pressured by nation states" attack already works against an iPhone (spoiler alert: it doesn't). Let's say you leave an iPhone on a table, the FBI takes it, and now Apple is required to unlock it (as in the San Bernardino case). I was a big name hitting Apple hard on this: they absolutely could bypass that phone, because they left themselves what amounted to a back door to do firmware upgrades without the user's permission (which was the actual issue at hand, not the "effort" to building a modified firmware image: anyone could have done that if Apple merely signed the result). However, this was fixed: firmware updates of both the OS and (as far as I know) the secure enclave now require the user to unlock the device. This unlock process is protected from brute force by the software running in this secure enclave, and Apple is unable to bypass it even if they are "pressured by nation states". They hadn't implemented this on the older devices, and I felt their stance in that case was thereby disingenuous, but they had already mostly fixed the issue in the subsequent already-released-at-the-time phone and they later fixed it even better. (Now, there are also was an exploit people found in those phones, but that's clearly a different problem.) What I am suggesting for this situation is to start with the iOS secure boot chain behavior but then implement a mechanism similar to the Android "wipe disk on bootloader unlock" solution that itself works similarly to the Android APK upgrade process: when a kernel is presented to the bootloader, instead of it being checked strictly for "is this signed by Apple", it would accept any kernel signed by any key... but instead of merely jumping into the kernel after loading it, it would pass the address of the memory region, the signature, and the entry point (edit: this bit needs to be inside of the signed kernel image) to the secure enclave, which would now verify the signature and jump to the entrypoint (instead of this being done directly by the secure bootloader). Since the secure enclave (which is of course immune to your blue pill attack) is now what verified the signature of the kernel, it would be able to use the hash of the public key of the certificate for the signature of the kernel as part of its key derivation path for subsequent encryption work. This would allow the full disk encryption--which is already being done in the secure enclave (keys are managed there, as you note, but without the issue you claim it has), to avoid the kernel having direct access to the root filesystem keys--to be "tied to" (which I honestly assumed anyone in this kind of discussion would understand immediately ;P) the kernel vendor (which might be the user, if they compile their own kernels: the user absolutely should be allowed to install their own kernels). (FWIW, if you want to blast me for "hand waiving" anything to the point where I imagine someone who works on this stuff wouldn't be able to quickly derive it, it is that I appreciate that kernels are usually stored on filesystems, causing a chicken-and-the-egg issue; but I personally have always found that to be incompetent, as it means that the second stage bootloader on iOS seriously has a full HFS+ filesystem parser, which has in the past been the source of bugs serious enough to cause key leakage :/. Just don't do that... somehow? Maybe do what Android does, with a separate flash partition for the kernel image? I certainly would admit that dealing with this quirk feels like a separate step.) What I like about this kind of scheme is that it makes the bootloader "work for the user" instead of merely working for Apple. It also doesn't leave the user stranded without secure boot if they want to boot their own kernel. I want a scheme where users can choose their own trust root, and that's effectively what this is automatically doing, with the secure enclave feeling more like a secure hardware piece than being relayed to the operating system. (This all said: I haven't looked at all into how the M1 works... the Apple engineers who work on this have shitty motivations and at-best-borderline morality, but they aren't stupid: if they actually got the green light to work on this, for all I know this is how it already operates. I also am only an expert on mobile systems in general, so I have never looked into the schemes developed by Microsoft and Intel... I kind of feel like, by default, they would suck, though :/.) I thereby feel like there is both a way it "should" work--which involves tying the full disk encryption to the key of the kernel vendor--which admittedly might be how it did work; but, either way: I believe that (barring mistakes in the implementation, which sadly almost certainly will exist, and may as well be "back doors" :/) it is at least possible (whether my suggestion was a complaint that Apple did it incorrectly or an accidental explanation for why they did correct) to do this without causing some kind of obvious "blue pill" attack (and yes, it does involve a secure enclave, but I believe the thing Apple does isn't as intrinsically evil as the thing Intel does, as the core problem is third-party attestation, as that is what gives you ridiculous DRM scenarios of your hardware hiding stuff from the user on behalf of the software instead of the other way around).

deleted 6y ago

[deleted]