I am going to do a Finalyear-project on two-factor authentication,where the second factor as digital certificate with the username/password.I have an idea of doing it for the web applications,how to do this with Java with sample digital certs. and is there any way that i can make use of any Cryptographic algorithms? what are the drawbacks associated with digital certficates?Please give me some details.
The easy approach is to use x.509 certificates. Oracle's Java™ PKI Programmer's Guide looks like it provides an excellent overview of the Java APIs necessary to use x.509 certificates. Many Java developers use the Bouncycastle package for additional cryptographic APIs.
The nice part of using x.509 certificates is that nearly everything supports them. You can easily plug x.509 client certificates into most web browsers and most web servers can be easily configured to accept them. Setting up your own Certificate Authority is pretty easy with the TinyCA program. (The openssl command line tools aren't awful, but TinyCA makes it point-and-click easy to get everything right.)
The biggest downside to x.509 is probably the awkwardness involved in setting up your own CA -- so many programs have a list of CA Root Certificates that are baked into the program and supplying your own Root Certificate can be annoying -- somehow you have to transport that file to your clients in a manner that prevents tampering. (A task that would be easier if your CA root were already in the software.)
Related
I'm adding SSL support (currently pushing forward with OpenSSL) to an existing application. I've never done anything with cryptology before and after reading numerous articles and watching videos I'm still a little confused as to how I can implement it for my specific situation.
Our software is client/server, and the end-user purchases both and will install it on their premises.
My first bit of confusion is regarding certificates and private keys, and how to manage these. Should I have one certificate that get installed along with the app? Should each end-user have their own certificate generated? What about private keys? Do I bake the private key into the server binary? Or should there be a file with the private key?
I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.
Thanks for any help and advice.
Adding OpenSSL into existing app
If all you need is an example of a SSL/TLS client, have a look at the OpenSSL's wiki and TLS Client example.
My first bit of confusion is regarding certificates and private keys, and how to manage these.
Yes, key management and distribution is the hardest problem in crpyto.
Public CAs have legally binding documents covering these practices. They are called Certification Practice Statements (CPS). You can have a lot of fun with them because the company lawyers tell you what you don't want to hear (or the marketing department refuses to tell you).
For example, here's an excerpt from Apple Inc. Certification Authority Certification Practice Statement:
2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements,
if applicable, disclaim warranties from Apple, including any
warranty of merchantability or fitness for a particular purpose.
2.4.3. CA limitations of liability
To the extent permitted by applicable law, Subscriber agreements,
if applicable, shall limit liability on the part of Apple and shall
exclude liability for indirect, special, incidental, and
consequential damages.
So, Apple is selling you a product with no warranty and that offers no liability!!! And they want you to trust them and give them money... what a racket! And its not just Apple - other CAs have equally obscene CPS'es.
Should I have one certificate that get installed along with the app?
It depends. If you are running your own PKI (i.e., you are the CA and control the root certificate), then distribute your root X509 certificate with you application and nothing else. There's no need to trust any other CAs, like Verisign or Startcom.
If you are using someone else's PKI (or the Internet's PKI specified in RFC 5280), then distribute only the root X509 certificate needed to validate the chain. In this case, you will distribute one CA's root X509 certificate for validation. You could potentially trust just about any certificate signed by that particular CA, however (and its likely to be in the 10's of thousands if you are not careful).
If you don't know in advance, then you have to do like browsers and pick a bunch of CAs to trust and carry around their root certificates for your application. You can grab a list of them from Mozilla, for example. You could potentially trust just about any certificate signed by all CAs, however (and its likely to be in the 10's of millions if you are not careful).
There's a lot more to using public CAs like browsers, and you should read through Peter Gutmann's Engineering Security. Pay particular attention to the Security Diversification strategies.
When the client connects to your server, your server should send its X509 certificate (the leaf certificate) and any intermediate certificates required to build a valid chain back to the root certificate you distribute.
Finally, you can get free SSL/TLS certificates trusted by most major browsers (including mobile) from Eddy Nigg at Startcom. He charges for the revocation (if needed) because that's where the cost lies. Other CAs charge you up front and pocket the proceeds if not needed.
Should each end-user have their own certificate generated?
That is possible, too. That's called client certificates or client authentication authentication. Ideally, you would be running your own PKI because (1) you control everything (including the CA operations) and don't need to trust anyone outside the organization; and (2) it can get expensive to have a commercial CA sign every user's certificate.
If you don't want to use client side certificates, please look into PSK (Preshared Keys) and SRP (Secure Remote Password). Both beat the snot out of classic X509 using RSA key transport. PSK and SRP do so because they provide mutual authentication and channel binding. In these systems, both the client and server know the secret or password and the channel is setup up; or one (or both) does not know and channel setup fails. The plain text username and password are never put on the wire as in RSA transport and basic_auth schemes. (I prefer SRP because its based on Diffie-Hellman, and have implemented it in a few systems).
What about private keys?
Yes, you need to manage the private keys associated with certificates. You can (1) store them in the filesystem with permissions or ACLs; (2) store them in a Keystore or Keychain like Android, Mac OS X, iOS, or Windows; (3) store them in an Hardware Security Module (HSM); or (4) store them remotely while keeping them online using Key Management Interop Protocol (KMIP).
Note: unattended key storage on a server is a problem without a solution. See, for example, Peter Gutmann's Engineering Security, page 368 under "Wicked Hard Problems" and "Problems without Solutions".
Do I bake the private key into the server binary?
No. You generate them when needed and then store them with the best protection you can provide.
Or should there be a file with the private key?
Yes, something like that. See above.
I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.
I'm not sure I would really call it solved because of the key distribution problem.
And some implementations are just really bad, so you would likely wonder how the code passed for production.
The first thing you probably want (since your focusing on key management) is a treatment of "key management" and "key hierarchies".
You might also want some reference material. From the security engineering point of view, read Gutmann's Engineering Security and Ross Anderson's Security Engineering. From an implementation standpoint, grab a copy of Network Security with OpenSSL and SSL and TLS: Designing and Building Secure Systems.
I generated selfsigned certifiacte to use it to authenticate my web appliaction. Clients instead of web browser use client application to comunicate with web server. Client application uses httpclient. The internet is full of examples of how to trust all the ssl certificates in httpclient. I don't want to trust all certificate, I want trust only one, my selfsigned certificate (of course every CA trusted certificate also). I know that I can add my certificate to trusted keystore using keytool, but I don't want to interface in JSSE keystore. I want to say httpclient to trust one specific selfsigned certificate.
First question:
Is it possible?
Second question:
Described solution is ok in development environment. I'm think that is bad practice, but I wonder that is it acceptable in production environment?
Is it possible?
Of course, it is. You just might need to do more work managing your trust material and initializing the SSL context for your application. You can choose to trust one and only certificate, or you can choose to use trust material shipped with JRE and then selectively add trust material specific to your application.
You could use SSLContextBuilder from Apache HttpClient 4.3 to simplify the process of trust and key material management and initialization
is it acceptable in production environment?
This very much depends on the security context and requirements of your application. Trusting only one specific certificate without trusting any of standard CAs might make your application marginally less susceptible to man-in-the-middle exploits but will require re-configuration and possibly redeployment every time the certificate in question expires or gets revoked. It will also become your responsibility to ensure that the private key will not fall into the wrong hands. It is a combination of pros and cons.
I have an OAuth2 api exposed that runs over HTTPS. Since OAuth2 relies on the security of HTTPS (doesn't do any of it's own signing) I added a note in the developer docs encouraging developers to make sure they validate the ssl certificate in their client applications.
I noticed that some apps make the crt file publicly available or include it in their client: https://github.com/stripe/stripe-ruby/tree/master/lib/data
I assume this is just to make sure it is using the right certs (and not any system installed ones)? If so, is it a good idea to make this crt file publicly available to developers on your API page and what is an easy command/way to generate this file?
Thanks!
When one makes the certificate public this way, he encourages clients to do binary comparison of certificates, i.e. validate the certificate not in a way defined by corresponding standards by building a certificate chain and validating them) but simply by comparing the presented certificate with the one stored in the client.
This method is broken in several ways:
binary comparison doesn't let the client know that the certificate was revoked
with binary comparison the change of server certificate would require updating all clients so that new certificate would be included there. Failure to upgrade would mean impossibility to connect.
Consequently inclusion of the certificate and "straightforward" use of such certificate makes no sense, neither for server owners nor for clients.
The only case when binary comparison is applicable is when self-signed certificates are used (in which case building and validating a chain won't work). But self-signed certificates is a bad idea in any case (due to reasons listed above and some other reasons).
I'm developing software which will be deployed using clickonce (on the website foo.com), and which will then connect to my server using WCF with an encrypted transport
So I need an SSL certificate which will :
Identify my foo.com website has really being my website
Identify the exe I deploy using clickonce as being genuine
Identify my application server has really being my application server.
I also want my SSL certificate to be signed by an authority known to the public (ie, firefox or windows won't ask the user to install the authority's certificate first !)
What SSL certificate would you buy?
I've browsed the Verisign website, the "Secure Site EV" certificate costs 1150€ a year (the "Pro" version seems useful only for compatibility with older browsers)
It sounds like you're looking for two different types of certificates:
1 - SSL Certificate - for authentication of your website/application server.
2 - Code Signing Certificate - for integrity/authentication of the exe you deliver.
Typically those are two different certificates, with two different certificate profiles. At the very least, you need one certificate with two different key usages or extended key usages.
A few thoughts in no specific order:
Check your targeted browsers, they should each have a set of preconfigured root certificates - those are the most widely recognized public certificate sources. I'd probably check both Firefox and IE. Certificate vendors known to me as big names are - Versign, GeoTrust, RSA, Thawte, Entrust. But there's also GoDaddy and many others. Anything that comes in the delivered browser as a Trusted Root Certificate, will allow you to connect to your users without additional greif.
I suggest Googling for both "code signing certificate" and "SSL certificate".
How you configure your site will determine whether or not your website is validated or your authentication server is validated. If the certificate is stored on the apps server, then your user is getting SSL encryption all the way to the server. But many sites put the SSL certificate a little farther forward - like on a firewall, and then stage a collection of apps servers behind it. I don't see a security flaw in that, so long as the networking is carefully configured. To the outside users, both configurations will look the same - they'll get the lock on their browsers and a certificate that tells them that www.foo.com is offering it's credentials.
I'm seeing pretty great deals for SSL Certificates:
- GoDaddy - $12.99
- Register.com - $14.99
But they aren't necessarily code signing certifiates. For example, while GoDaddy's SSL Cert is $12.99, their code signing certs are $199.99! That's part of many certificate vendors business models - lure you in with cheap SSL Certs, and make you pay for code signing. A case could be made that code signing certificates are relatively higher liability. But also... they have to subsidize the cheap SSL certs somehow.
Theoretically, it should be possible to make a certificate that does both code signing and SSL, but I'm not sure you want that. If something should happen, it would be nice to be able to isolate the two functions. Also, I'm pretty sure you'd have to call the certificate vendors and ask if they did this, and if they don't, having them do it will likely jack up the price quite high.
As far as vendor, things to consider:
The technology is pretty much all the same. These days, aim for a minimum of 128 bit keys, I'd probably bump it up to 256, but I'm paranoid.
Beyond browser acceptabiliy, the only reason to pay more would be name recognition. Among the paranoid security wonks, I'd expect RSA, Thawte, Verisign and GeoTrust to have very good reputations. Probably EnTrust, too. This probably only matters if you are dealing with a security focused product. I think your average user will not be so aware.
From a security geek perspective - you're only as safe as the security of your Root CA (Certificate Authority). For the truly paranoid, the thing to do would be to dig into the background material of how the company hosts its root and issuing CAs, how are they physically securited? network security? personnel access control? Also - do they have public CRLs (Certificate Revocation Lists), how do you get a cert revoked? Do they offer OCSP (Online Certificate Status Protocol)? How do they check out certificate requestors to be sure they are giving the right cert to the right person? ... All this stuff really matters if you are offering something that must be highly secure. Things like medical records, financial managment applications, tax information, etc should be highly protected. Most web apps aren't so high risk and probably don't require this degree of scrutiny.
On that last bullet - if you dig into the Verisigns of the world - the very expensive certs - you're likely to see the value. They have a massive infrastructure and take the security of their CAs very seriously. I'm not so sure about the super-cheap hosting services. That said, if your risk is low, US$300 for an SSL Cert doesn't make much sense compared to US$12.99!!
So for web site / application servers you need an SSL certificate. You do not need an EV certificate. I've used ones from QuickSSL for this, as unlike some of the other cheap certificate providers they don't require the installation of an intermediate certificate on the server - that's a no-one for me.
For signing applications that's a different type of certificate altogether (kind of, it's still an X509 certificate, but the one you use for your web site is not one you can use to sign an application). You need an authenticode signing certificate from the likes of Verisign or Globalsign. These are a magnitude more expensive than a plain old SSL certificate and require you to be an incorporated company and produce those documents.
I am presently studying the topic of encrypting and signing SOAP messages via WSE 3.0 or WCF. Since I have not participated in distributed application development involving the public Internet, I find my knowledge on X.509 ceritificates lacking and how it works in the Windows certificate store mechanism. It is not about asymmetric cryptography; it is about the PKI ecosystem.
Therefore I would like to gather what are some articles or books that give comprehensive explanations on Windows' security mechanisms, how to properly use and manage the Certificate Store, CA trust chains, and how APIs like WSE or WCF may interact and make use of certificates. Recommendations?
Everyone using (or thinking of using) X.509 certificates should be forced to read this: Everything you Never Wanted to Know about PKI but were Forced to Find Out, as well as X.509 Style guide, both by Peter Gutmann.
I think the base starting point to understanding the Windows implementation of PKI has to come from TechNet
PKI segment
http://technet.microsoft.com/en-us/library/cc757327(WS.10).aspx
Certificates overview
http://technet.microsoft.com/en-us/library/cc784662(WS.10).aspx
Certificate services
http://technet.microsoft.com/en-us/library/cc783511(WS.10).aspx
Certificate templates
http://technet.microsoft.com/en-us/library/cc758496(WS.10).aspx
"Learning WCF" by Michele Bustamente has a good overview chapter on WCF security, including some basic discussion on X.509 certificates.
From the MSDN:
How to: Decrypt XML with x509
How to: Encrypt XML with x509