0

i was wondering, let's say i have an executable A, which verifies a certificate in assembly B.

Assembly B is signed with root ca trusted certificate.

what denies me from taking executable A, change it and skip the certificate check of B?

i guess executable A needs to be signed aswell, but what happens if it's not? or what happens if i take also executable A, and signs it with my own malicious self signed certificate?

thanks

|improve this question
0

what denies me from taking executable A, change it and skip the certificate check of B?

this is why standard users shall not have write access to application binary modules. They should be able to execute, but not modify. In addition, there might be used some application whitelisting platform to control which executables are allowed to run. Even if you sign the application with your own certificate, it won't be executed, because AWL software will not recognize it as trusted.

|improve this answer
  • allright, so we're always counting on some third party whitelisting platform. if this doesnt exist, we only protect against standard users, and not against administrative one (which can theoretically do what i said - unless there's some kind of platform to protect against that). correct? – ArielB Dec 6 '16 at 12:58
  • Yes. Administrators can do on their systems whatever they want/need. – Crypt32 Dec 6 '16 at 13:08
1

Quis custodiet ipsos custodes

In the case where one party is an executable and the other is a certificate, it is not possible to assure mutual verification - hence if A validates B and you need C to validate A.

If we were simply talking about 2 certificates, then mutual authentication is possible as signatures can be added to the entity without changing the signed part. Unfortunately x509 only permits a single signature on a certificate, and given that the trust model isn't really designed to work in this way, there may be complications with the tools to this approach (since at least one signing will require to be done with an unsigned certificate).

But I digress from the problem asked.

A needs to be signed aswell

But for this to to have any value, the signature on A needs to be checked - hence C. And how do you validate 'C' - it's turtles all the way down.

...or at least till the point where it is out of your control, be that because you are constrained by the permissions configured by the admin or the trusted keys in UEFI or a root Certificate Authority (this does not mean that that your admins or hardware vendors or Certificate Authorities are implicitly trustworthy though).

It may be worth noting here that public PGP keys can have multiple signatories which, interestingly, would allow the OS to (within some limitations) validate the hardware as well as the hardware validating the boot OS in a Secure boot - but sadly "Secure boot" uses x509.

|improve this answer
  • i agree, so eventually the "C" (or whoever is above it) needs to be protected in a way CryptoGuy mentioned. for example by an endpoint protection product which will protect modification on "C". – ArielB Dec 7 '16 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.