certificate embedded into the executable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

certificate embedded into the executable

James Whitwell
Hi,

Can anyone tell me if it's possible to embed a client certificate inside
my executable, and what calls I should use to tell OpenSSL to use it?  I
think I'll also need to do it for the CA, since we use self-signed
certificates, and I want the client to verify the server's certificate too.

Thanks,
;) james.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
C L
Reply | Threaded
Open this post in threaded view
|

RE: certificate embedded into the executable

C L
Theoretically it's possible to embed certificates into a Windows and Linux
executables - not sure about other architectures though.

In my spare time I've been researching this topic as well.  You can use the
ImageAddCertificate() Win32 API from Imagehlp.dll to programmatically store
a certificate inside of an executable.  I'm not sure what format the
certificate has to be in, but knowing Micro$oft it whould have to be PKCS#7
or is it #12? - I forget which now.

As for Linux, it's possible to create another data segment and store the
certificate into that.

In either architecture, OpenSSL will not be able to read directly from the
executable image.  You will need to develop a way to programmatically
extract from the executable image the certificate as binary data blob (see
the other APIs Imagehlp.dll exports) and supply it to openssl via an
in-memory BIO.

I hope this gives you some pointers on where to look next though.


>
>Hi,
>
>Can anyone tell me if it's possible to embed a client certificate inside my
>executable, and what calls I should use to tell OpenSSL to use it?  I think
>I'll also need to do it for the CA, since we use self-signed certificates,
>and I want the client to verify the server's certificate too.
>
>Thanks,
>;) james.
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Tan Eng Ten
In reply to this post by James Whitwell
Try if below works for you:

unsigned char buf[] = "----- BEGIN CERTIFICATE ----- ... ----- END
CERTIFICATE -----"; /* copy the entire certificate file (PEM formatted)
and stick it in here */

BIO *bio = NULL;
X509 *x509 = NULL;

bio = BIO_new_mem_buf(buf, -1);
x509 = PEM_read_bio_X509(bio, NULL, NULL, NULL);

-Tan Eng Ten

James Whitwell wrote:

> Hi,
>
> Can anyone tell me if it's possible to embed a client certificate inside
> my executable, and what calls I should use to tell OpenSSL to use it?  I
> think I'll also need to do it for the CA, since we use self-signed
> certificates, and I want the client to verify the server's certificate too.
>
> Thanks,
> ;) james.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Bear Giles
In reply to this post by C L
C L wrote:
> Theoretically it's possible to embed certificates into a Windows and
> Linux executables - not sure about other architectures though.

I don't recall the exact invocation off the top of my head but you
can create a make rule that's something like:

  cert.o: cert.pem
     ld -o $@ (flags) $<

and that will convert the specified PEM (or DER) files into data
segments with external symbols providing the caddr_t (char *) and
size.  Something like const char * cert_data and size_t cert_size.
You can then declare the symbols as 'extern' in your source code
and treat it like any other buffer loaded from disk.

Alternately you can explicitly include the cert as a constant
string.  It works but requires you to manually maintain that code.
 The linker will always use the current files.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Dr. Stephen Henson
In reply to this post by James Whitwell
On Tue, Aug 16, 2005, James Whitwell wrote:

> Hi,
>
> Can anyone tell me if it's possible to embed a client certificate inside
> my executable, and what calls I should use to tell OpenSSL to use it?  I
> think I'll also need to do it for the CA, since we use self-signed
> certificates, and I want the client to verify the server's certificate too.
>

Depends on whether you want it embedded in the executable after it has been
linked or at compile time, i.e. embedded in a C source file.

At compile time there is the -C command line switch in the 'x509' utility which
will convert the certificte into a C character array. From there you can just
use the d2i_X509() function on it.

An alternative which works for other file formats as well is to use the U*ix
xxd utility. E.g. xxd -i something.der

If this is used for any kind of security you might consider obscuring the
certificate in some way, to avoid simple replacement with a hex editor. Though
a determined and knowledgeable attacker wont be so easily foiled.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Bear Giles
Dr. Stephen Henson wrote:
> Depends on whether you want it embedded in the executable after it has been
> linked or at compile time, i.e. embedded in a C source file.

I think this is slightly off, but at link time (using the gnu tool
chain) you can use:

  ld -b binary -r -o root.o root.pem

then in your program

  extern const char _binary_root_pem_start[];

will contain the contents of 'root.pem'.  The object table
includes "_binary_root_pem_size" and "_binary_root_pem_end" but
it's too early in the morning to figure out why I'm having trouble
accessing those values.

There should be something in the archives in mid-late 2002 (iirc).

> If this is used for any kind of security you might consider obscuring the
> certificate in some way, to avoid simple replacement with a hex editor. Though
> a determined and knowledgeable attacker wont be so easily foiled.

A determined and knowledgable attacker can subvert anything that's
not in hardware.  Pulling a cert from a server isn't that much
harder to break given that it's trivial to set up a local DNS
server that will redirect queries to the attacker's own server.
(Or to simply use the same editor to replace your URL with their
own.)  Another attack is to attach to the process, stop it after
the cert has been loaded, then replace that cert with the attacker's.

One positive thing: if you're operating at this level it's trivial
to use encryption and hashing to hide the cert and verify it has
not altered.  It's not perfect and you'll still need to embed an
encryption key.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: certificate embedded into the executable

JoelKatz
In reply to this post by Bear Giles

>   cert.o: cert.pem
>      ld -o $@ (flags) $<

        Or even:

%.h: %.pem
        xxd -i $< > $@

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: certificate embedded into the executable

JoelKatz
In reply to this post by Bear Giles

> Dr. Stephen Henson wrote:

> A determined and knowledgable attacker can subvert anything that's
> not in hardware.

        I think this is a very strange thing to say. If he has access to the
hardware, he can subvert it too. If he doesn't have access to the hardware,
how can he subvert the software?

> Pulling a cert from a server isn't that much
> harder to break given that it's trivial to set up a local DNS
> server that will redirect queries to the attacker's own server.

        So sign the cert. No hardware needed.

> (Or to simply use the same editor to replace your URL with their
> own.)

        Sure, if you have access to the software. If you have access to any
security scheme, you can simply disable the scheme.

> Another attack is to attach to the process, stop it after
> the cert has been loaded, then replace that cert with the attacker's.

        If you have that level of control over the process, you can make the
process do anything you want, but you could just do what you wanted anyway
with that level of control over the system. So what do you need the process
for?

> One positive thing: if you're operating at this level it's trivial
> to use encryption and hashing to hide the cert and verify it has
> not altered.  It's not perfect and you'll still need to embed an
> encryption key.

        If someone wants to alter the certificate that secures their own machine,
why should I care? You can certainly break things that you are allowed
access to.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Dr. Stephen Henson
On Tue, Aug 16, 2005, David Schwartz wrote:

>
> > Dr. Stephen Henson wrote:
>
> > A determined and knowledgable attacker can subvert anything that's
> > not in hardware.
>
> I think this is a very strange thing to say. If he has access to the
> hardware, he can subvert it too. If he doesn't have access to the hardware,
> how can he subvert the software?
>

I didn't say it...

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Bear Giles
In reply to this post by JoelKatz
David Schwartz wrote:
> %.h: %.pem
> xxd -i $< > $@

That's compile time so it's not quite as flexible as the link time
command.

Why does this matter?  You might have a situation where the source
code is managed by one group without access to the PKI objects,
and the PKI objects are managed by another group without access to
the code.  That's a moot point with the full GNU toolchain but
they might only be provided with a stripped down linker.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: certificate embedded into the executable

Bear Giles
In reply to this post by JoelKatz
David Schwartz wrote:
>>Dr. Stephen Henson wrote:
>
>>A determined and knowledgable attacker can subvert anything that's
>>not in hardware.
>
> I think this is a very strange thing to say. If he has access to the
> hardware, he can subvert it too. If he doesn't have access to the hardware,
> how can he subvert the software?

Software is exploited or subverted all of the time without access
to the physical hardware.  You don't even need a shell account on
the system if there's a remote exploit.

Most, but not all, hardware can be compromised if you have
physical access.  Hardened equipment is not cheap.

>>Pulling a cert from a server isn't that much
>>harder to break given that it's trivial to set up a local DNS
>>server that will redirect queries to the attacker's own server.
>  
> So sign the cert. No hardware needed.

How do you verify it's ultimately signed by the right certificate?
     You need to get the root certificate from somewhere.

>>(Or to simply use the same editor to replace your URL with their
>>own.)
>
> Sure, if you have access to the software. If you have access to any
> security scheme, you can simply disable the scheme.

The original context was Dr. Henson's well-grounded observation
that anyone with a hex editor could easily change an embedded
certificate.  Once you have access to the software then anything
in it, or its environment, can be changed at will.

> If you have that level of control over the process, you can make the
> process do anything you want, but you could just do what you wanted anyway
> with that level of control over the system. So what do you need the process
> for?
>
> If someone wants to alter the certificate that secures their own machine,
> why should I care? You can certainly break things that you are allowed
> access to.

Reread what you just wrote - what if the certificate is used to
verify credentials provided by others to gain access?  (BTW don't
assume it's only protecting a machine.  Maybe this is part of an
application that controls access to extremely expensive or
sensitive material.)  Give me the ability to reset the root
certificate and I have an unlimited pass throughout your system.
Potentially worse I can deny access to your legitimate users.

Another example of a certificate as a credential - license keys.
Maybe we're talking about software that normally sells for $10k,
but also has a $100 student version with limited functionality.
Same software, but I think most of us can see how the company will
make a distinction between the guy who paid nothing, the student
who got an educational version, and the company that bought a full
license.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: certificate embedded into the executable

JoelKatz

> David Schwartz wrote:

> >>Dr. Stephen Henson wrote:
> >
> >>A determined and knowledgable attacker can subvert anything that's
> >>not in hardware.
> >
> > I think this is a very strange thing to say. If he has access to the
> > hardware, he can subvert it too. If he doesn't have access to
> > the hardware,
> > how can he subvert the software?

> Software is exploited or subverted all of the time without access
> to the physical hardware.  You don't even need a shell account on
> the system if there's a remote exploit.

        Hardware can likewise be exploited without physical access.

> Most, but not all, hardware can be compromised if you have
> physical access.  Hardened equipment is not cheap.

        Any mechanism that can compromise one can compromise the other. Both
hardware and software are really combinations of both.

> >>Pulling a cert from a server isn't that much
> >>harder to break given that it's trivial to set up a local DNS
> >>server that will redirect queries to the attacker's own server.
> >
> > So sign the cert. No hardware needed.

> How do you verify it's ultimately signed by the right certificate?
>      You need to get the root certificate from somewhere.

        And hardware solves this?!

> >>(Or to simply use the same editor to replace your URL with their
> >>own.)
> >
> > Sure, if you have access to the software. If you have access to any
> > security scheme, you can simply disable the scheme.

> The original context was Dr. Henson's well-grounded observation
> that anyone with a hex editor could easily change an embedded
> certificate.  Once you have access to the software then anything
> in it, or its environment, can be changed at will.

        Who cares? Anyone who can modify the software is the person the software is
supposed to serve. If they want to compromise their own security, let them.

> > If you have that level of control over the process, you can make the
> > process do anything you want, but you could just do what you
> wanted anyway
> > with that level of control over the system. So what do you need
> the process
> > for?
> >
> > If someone wants to alter the certificate that secures
> their own machine,
> > why should I care? You can certainly break things that you are allowed
> > access to.

> Reread what you just wrote - what if the certificate is used to
> verify credentials provided by others to gain access?

        Then anyone who can modify the software can control which others gain
access. That sounds right to me.

> (BTW don't
> assume it's only protecting a machine.  Maybe this is part of an
> application that controls access to extremely expensive or
> sensitive material.)

        If you have control over the process that controls access to the material,
you control the material.

> Give me the ability to reset the root
> certificate and I have an unlimited pass throughout your system.
> Potentially worse I can deny access to your legitimate users.

        Right, that's why I wouldn't give you that ability. I can't possibly
comprehend this hypothetical. We're assuming a person has access to the
process that controls access to the system but we're not assuming he
controls access to the system? That makes no sense.

> Another example of a certificate as a credential - license keys.
> Maybe we're talking about software that normally sells for $10k,
> but also has a $100 student version with limited functionality.
> Same software, but I think most of us can see how the company will
> make a distinction between the guy who paid nothing, the student
> who got an educational version, and the company that bought a full
> license.

        Say the code that provides the advanced functionality is encrypted and
their license allows them to decrypt it. If they don't have a license, they
can't decrypt the code no matter what, changing things in the software won't
help them. If you don't want someone to get to some information, you encrypt
it and don't give them the key. Now they can't get to it (whether they use
hardware or software, no matter, they can't get to it).

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]