I guess I'll have to reply by-line:
Sorry for my noobness... I do not have a PhD in cryptography.
The requirements say "positive integers count from the leaf (0) toward the anchor" and "the value for the leaf certificate and root certificate are 0 and -1, respectively". If you found a typo, contact Apple.
OK... looks like an inconsistency/typo in the docs provided by Apple (no surprise there). I was just trying to make sure I understood the substitutions you were making.
There are a whole bunch of issues here.
[*]I drew your attention to these OIDs back when kext certificates became available, you demurred. Just because a certificate says Developer ID doesn't mean it passes Apple's requirements for kexts.
I realize that, but was under the impression that gatebreak was intended to bypass the kext signing requirements.
[*]Kext certificates look almost exactly the same except for ...6.1.13 and ...6.1.18. Again, I called your attention to this a long time ago.
[*]Trying a normal Developer ID, or bypassing the specific requirements is pointless, you might as well not check certificates at all.
Again, I thought the purpose of gatebreak was so signing with a kext cert was not necessary. And I see what you're doing now... you're using a kind of 'fake' kext cert...
And I think I get it, your requirements are tighter and still check that the kexts are signed like a kext would normally be signed, but eliminating the requirements that they use an apple cert. Because it is impossible to get an apple cert that satisfies all the requirements without requesting one from apple and exposing identity when the kext is made available for download.
[*]Running `codesign` without specifying the code requirement only confirms that the signature itself is valid.
So... when I run codesign, I must specify the 'code requirement' as well as the cert, which presumably already has this information?
And to sign I need to use -r "((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted) and (cert leaf[field.1.2.840.113635.100.6.1.13] and cert 0[field.1.2.840.113635.100.6.1.18])"
And the cert needs to have the ...1.13 and ...1.18 capability injected into it? I will look further into your script and see if I can generate such a cert.
I would appreciate any insight you might have on the specific params I should use for codesign.
[*]`kextutil -tn <kext>` is a safe way to test kexts
Great tip for quick checking. Final test is kextcache/kextload for me...
[*]You should be signing the patched binaries with another certificate to replace the seals broken by patching, making sure to preserve the existing metadata. Without an exact match, they might as well be unsigned.
As I noted, the binaries don't even need to be re-signed. It looks like a major hole in Apple's security here.
What do you mean by "making sure to preserve the existing metadata?" Is there some specific param to accomplish that in codesign?
If you could publish the codesign command lines you use for signing both the FakeSMC.kext and the binaries, that would be great.
[*]My objective was to create a system with no dependencies on Apple, that's why I posted all of the materials necessary to create a certificate authority which passes the requirements. I even annotated the OIDs so others could make sense of them.[/list]
But we still have the (as an intentional choice) dependency on the ...1.13 and ...1.18, although you're able to inject those into a non-Apple cert. At least that's my noob understanding at the moment.
The script I provided does (nearly) all of the work, so I don't see why you would use Certificate Assistant, knowing or not that it can't even create these kinds of certificates anyway.
You can't sign with the Gatebreak root certificate because I've only provided the public key which cannot be used to sign, only verify. I think you need to reread my three threads on this topic.
So the gatebreak cert is only useful to those using your FakeSMC.kext... It is not useful for others wishing to sign additional kexts. I thought you were implying otherwise when you wrote "The point of this method isn't to spawn tens or hundreds of independent authorities for signed kexts, whenever possible groups should create one authority: by website, working group, or other affiliation."
So although you wrote that in the subject documenting the process of creating the gatebreak cert, it is not your intention that the gatebreak cert is to be used that way (gatebreak is not "working group, or other affiliation"). The gatebreak cert is only useful as a signing authority for the kexts/binaries *you* plan on distributing.
Correct?
----
I will look further into creating my own cert with your script...
---
One other item...
If I understand correctly, we could simplify the code requirements from:
Code:
((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted) and (cert leaf[field.1.2.840.113635.100.6.1.13] and cert 0[field.1.2.840.113635.100.6.1.18])
To:
Code:
anchor trusted and cert leaf[field.1.2.840.113635.100.6.1.13] and cert leaf[field.1.2.840.113635.100.6.1.18]
My reasoning is this...
The expression '((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted)' allows either '(anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6])' OR just 'anchor trusted' to satisfy the requirement. All signatures that satisfy the first (left of 'or') will satisfy the second (right of 'or').
In other words, it is like:
can be simplified to:
Please correct me if I'm wrong. Thanks!