On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener <el...@tropicsoft.com> wrote:
> Kyle Hamilton wrote:
>>
>> If you're on Windows, it does make sense to include the PEMs for the
>> CA (and chain) in the application directory. (See, for example, the
>> software distribution of Second Life, which has its own CA for TLS
>> authentication of its own grid servers.)
>>
>> For client certificates, though, it depends. If it's a per-user
>> certificate, the certificate (and key) should go in the user's home
>> directory (in a folder not unlike, but also not, ~/.ssh) -- and should
>> have permissions which only allow the user access. If it's a
>> per-machine certificate, the certificate (and key) should go under
>> either /etc/ or /var/ (on *nix) or the application directory (on
>> Windows).
>
> It is a per-machine cert in my case under Windows. But it is solely for the
> use of a single application. I certainly can distribute the certs in the
> common application directory under Windows but that complicates the issue
> under Windows Vista protected mode, where certain directories are off-limits
> to a running application unless the application runs with Administrator
> rights, which is something not being required of the end user once the
> application has been installed. Nonetheless it is a good idea to consider.
> At least the certs are more hidden there than in the application directory.
If it's under Windows, you can place the certificate (and key) in your
app's registry. You could also use the so-called "native" API to
embed a NUL character ('\0') in the name of the key you place it in.
See http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx for
information on this (look for "Hidden Registry Keys" on the page);
however, be aware that many rootkit scanners will find and delete
these WinSDK-inaccessible entries.
This is a red flag to most security-conscious hackers, though, and
many will do anything they can to figure out what's in there.
Also, the host/port must be considered public information. They can
be easily derived with netstat.
> If I encrypt the cert files pre-installation I would use the the Windows
> Crypto API library to do so, and then use the same library at run-time to
> decrypt it and put it someplace temporarily in order to user the cert files.
> I have already used the Crypto API successfully so I know it can be done
> fairly easily.
If you're using CryptoAPI, why are you not using it for key storage as well?
> I do not think I really need to scramble anything once the data is encrypted
> as the "strings" are just totally encrypted sequences of byte information
> once Crypto API encrypts them.
The openssl library (libeay) can do everything that cryptoAPI can do,
as well. It doesn't use the same API convention, though.
> This is potentially a very good idea. At least I could keep everyone except
> my application from easily viewing the certs.
No, since your application runs with the user's rights, the user must
be able to read the certs and key.
> It is my employer who has been told that
> distributing the certs so that an end user can easily view them is a
> security risk.
This is absolute garbage. The idea behind certificates is that they
uniquely identify the consumer's public key (and thus the private key
they use with it), and they're signed by someone you trust. You can
also embed a critical extension in the certificate so that no other
X.509 application would or could use it. You don't have to put any
kind of private or confidential data in the certificate itself. (It
is the PRIVATE KEY which must be kept protected.)
I'd like to know the name of the rep at Sun who told your employer
this, so I can go to Sun and say "you need to train your developer
liaisons better about X.509 and asymmetric cryptography."
> My own viewpoint is that the certs are useless without
> host-name/username/password/database knowledge of the server database anyway
> so there is little point really in inventing elaborate measures to hide the
> certs from the end users eyes.
MySQL uses the certificate itself to identify the user to the
database, avoiding the use of a password entirely -- but only if the
certificate is issued by a trusted authority. The hostname/port is
public information (remember, netstat). The username which is used to
authenticate to the application is tested against the database, and
the password is as well. (You are remembering not to store the users'
passwords in clear-text, right?)
> But he has asked me to investigate the ways it can be done nonetheless.
You should instead be focusing on mitigating what happens WHEN (not
IF, because it WILL HAPPEN) someone manages to break the security of
your application and server. That's where you should be focusing your
development time/effort, not on some "makes the manager feel warm and
fuzzy" security theater. (You have my authorization to print out this
message and share it with him, if you think it would do any good.)
>> Depending on
>> how important it is that the data be secure, you may need to ensure
>> that a given client key is only used from a specific IP address or IP
>> range...
>
> It is an application to be sold to end users, so the 'from' IP address can
> not be pre-established. We do have ways from within the application to make
> sure that the client is a registered user which takes into account the
> client's machine. But of course a destructive hacker who could use the
> client certs along with the host-name/username/password/database knowledge
> to access the database is not running from within the application.
This is what needs to be mitigated, not "the access to read the certificate".
Then again, if your boss is really THAT paranoid, you should be
creating the keypair on the client machine, sending the public key in
for signing by your own CA, and using the certificate that's been
returned. This could be done during installation, or upon realization
that an anti-rootkit software erased the private key and certificate.
>> and you may also need to be on the lookout for inappropriate
>> access patterns (any 'select *', for example, if your application
>> doesn't use that means of getting data out of the tables) -- and if
>> you do see it, boot the connection from the server and invalidate the
>> client authentication credentials.
>
> I do not know how I can 'see' such patterns from within the application
> itself. I do not think a destructive hacker can easily change the
> application, even knowing the client certs, but maybe there are ways and I
> am willing to be educated about them.
http://www.acm.uiuc.edu/sigmil/RevEng/ has an (incomplete) book on the
matter. There's also a whole slough of books on reverse engineering.
Remember, once the application leaves your machine, it is running in a
hostile world. You cannot trust the application. You cannot trust
that just because that the other end of the connection knows the
secret key (and provides the certificate) you can assume that it's an
unmodified application. You should not try to detect this from your
application -- the only thing that you have control over is the
database, and the point where the application interacts with the
database is the "demarcation" -- you get to choose what information
comes over that link that you want to act upon.
This may require modifications to the MySQL server itself, to detect
these issues -- but, the server is the only place that you can place
your control.
One of the maxims of security-conscious programming is: "always assume
that the client is hostile." Don't ever provide any more services
than the blessed client will use.
Also, be aware that many hotels block connections to port 3306 (and,
in fact, to anything other than SMTP and HTTP/HTTPS). If this is
designed to be for the end-user on-the-go, you really shouldn't try
using a raw MySQL connection. Instead, make a web service (xml-rpc)
and perform all of your access- and bounds-checking there.
> Thanks for your suggestions, especially about the ACLs, which can fairly
> easily be manipulated by the installation program.
With this new information about what you're doing, I'd like to know
what the name of your software is so that I can avoid it. What you're
doing is security theater, not true security.
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
