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
Related
I'm looking at how to set up a secure connection between a WCF service, and a non-.NET client running on RHEL, so I expect Windows authentication is not feasible. This is just for an internal network, so I'm hoping to avoid the management headaches of X.509 (e.g. needing to closely monitor certificate expiry dates), but I'm not clear on whether it's technically possible to do so.
Is it possible to configure a WCF service with e.g. BasicHttpBinding or WsHttpBinding so that it has encryption (either transport or message layer, I'm not picky), but without using Windows authentication support or X.509 certificates?
Every scenario I've read for secured WCF services seems to use one of those two technologies. The only ones which don't require any X.509 certificates all use Windows authentication. I'm not sure if this is a fundamental consequence of the underlying technologies or if it's just a property of the "common scenarios" that Microsoft has chosen to document. At the moment I'm assuming that if Windows authentication isn't available, then X.509 is the only way to deploy public/private key pairs for the non-Windows-specific message encryption algorithms to use. Is this understanding correct?
well ... it's just that "common" property ...
x.509 is the common way to do this in your scenario, since the most things needed for this are already there ...
but you are not limited to either windows auth or x.509 ...
take a look here: http://www.codeproject.com/Articles/165844/WCF-Client-Server-Application-with-Custom-Authenti
the article describes how you can introduce your own authentication and encryption schema ...
i've already done that (simple AES encryption, one key among all clients), but i don't have the code at hand ... it wasn't that hard, but if you really run into trouble here, i'll have a look if i still have that stuff somewhere...
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 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.)
I have a client/server WCF application that needs some sort of user authentication against a database. The application (both client and server together) is being developed to be sold to dozens of customers, for use on their intranets. We're not too worried about encrypting most of the data moving across the wire, except of course during authentication.
Thinking about WCF security, I keep coming back to the idea that we should be making use of x509 certificates. However, our customers will definitely not want to know about any of the details of having to apply for, purchase and install these certificates.
I'd like to know first of all what the preferred method is of implementing username/password authentication in this scenario. If it will require using certificates, must the customer apply for their own certs from a trusted CA, or can we as the software provider generate certificates for the customer to use?
Really I'm looking for a best practice, with the least friction to our customers.
Thanks!
Edit: I'm using NetTcpBinding, and my server is running as a Windows Service.
So username/passwords does not require client certificates as I'm sure you're aware, it simply requires an HTTPS certificate on the server hosting the WCF service - once you have that you can happily use the standard username/password auth bits (WCF will not allow message based authentication without HTTPS).
If you wanted to head down the client certificate root you get the advantage of non-repudiation - you can be sure that the machine sending is who it says it is (unless someone has stolen the certificate, which is less likely than a username and password combination going walk about). You as the software provider could act as your own certificate authority and generate your own client certs (there are a few ways to do this depending on your infrastructure) but then you need to configure the clients to trust your root CA.
If the server and client are running in a domain environment you could use transport security with Windows authentication (you're using tcp binding, so interoperability is out the window anyway!) The added bonus to this is the authentication is transparent and you don't need any certificates anywhere. If you want verfication of the server identity then message security with Windows authentication will do the trick.
I've got project in production which is similar to your scenario. I have a Windows Service hosting endpoints via netTCPBinding and I used x509 certs... although in my case, the intent was to encrypt both the transport and message layers, as I was crossing over untrusted security boundaries. I was less concerned with providing authentication/authorization other than requiring the certificate be present.
Similar to your intranet scenarios (I'm assuming), I had authority over the server and client machines at installation time... or at least could dictate some of the terms of installation.
Rather than purchase the x509 certs and burden the client with that expense, I opted to roll our own. We set up one of our Win2003 servers to be a CA, issuing our own Certification Authority cert. We then generated an x509 cert for the server, as well as individual x509 certs for the clients.
The client and server certs were installed on both clients and server (as appropriate) into the personal user store at the computer level. We also installed our CA cert directly into the Trusted Root Certification Authorities section, thus making our client and server certs trusted.
Because I was less concerned with authentication/authorization, I don't know what to recommend as a best practice for dealing with binding certs to individual users and going more granular than machine-level (my solution was windows service to windows service communication -- completely unattended). I would think you'd need a cert for each user, installing it into their personal user store in the certificates MMC. The runtime implementation will be guided by how you configure WCF to do the cert lookup, so it should be fairly easy.
Throughout the process, I relied heavily on what I'd learned from this great CodeProject article: Securing WCF Services with Certificates. It walks you through generating/installing the certs. The sample WCF applicatoin is IIS-hosted, but I was able to pretty easily translate the config sections from web.config to app.config.
In my case, I exposed the Web interface for requesting certificates in Win2003 to the web itself, so the client could request certificates directly in the future. We have approval control, so it works well. I haven't had a need to generate new certs yet, so I can't say how much friction that would entail.
If your going to be crossing firewall boundaries then certificates are going to be your best solution. I don't know much about the specifics about applications for certificates or your application. Unfortunately, as far as i know, i think you will have to help them apply for certificates or they will have to do it their self unless they want to undertake in the process of installing their own certificate server. If the app will be internal then windows authentication will work and is VERY easy but if you think your going to have clients that user your application across firewall boundaries then you might as well invest the time in using certificates because certificates will work everywhere. Now there is something called federated security where you delegate the permission of authentication to another entity. I think this is used if say you have to domains and you want to delegate permission say of someone on another domain that is not on your domain to their domain but its pretty complex and my understanding of its very limited but by the sound of your requirements certificates is the way to go.
Security is not supposed to be easy :)
As far as I know only a subset of WS-Security version 1.0 is supported in NETCF and it uses X.509 certificates.
How can I obtain such a certificate to implement it in my application and prevent others to use my WCF service?
This article describes how to create an X.509 certificate. And this one describes how to make a certificate accessible to WCF.