xi2pay
asked on
Real world PKI use
I am familiar with the concept of PKI and how it works in theory. I however have been unable to find an article explaining it's real world use. Can someone please provide some practical, real-world examples? For example, how does Active Directory factor in with PKI? What common application use PKI? And so forth.
I have recently heard conversations regarding moving to Windows Server 2008 and Bitlocker (I believe it was bitlocker anway). Can someone tell me why a PKI solution would be required in this scenario?
I have recently heard conversations regarding moving to Windows Server 2008 and Bitlocker (I believe it was bitlocker anway). Can someone tell me why a PKI solution would be required in this scenario?
Bitlocker is a whole-disk encryption. To encrypt, you need a certificate or use password protected encryption. Using a certificate makes dealing with encryption much more managable, and increases the overall level of security as the public/private keypair is much more secure than just a password.
This could be a self-signed certificate, in which no PKI is needed. This might be fine for a home user - although they are more likely to never back up that key and make all of their data unrecoverable.
In the business world, encryption is a touchy subject. One the one hand, you need to protect your data - so you need encryption. On the other hand, you need to be able to recover all the data that belongs to your organization and for other legal needs, so encryption gets in the way.
A properly set up PKI will have recovery agent certificates set up for various encryption certificates. These do not affect signing-only certificates. This allows a restricted couple of people (usually only one or two people, even in large organizations there are just a few) to decrypt the encrypted data. This may be done like in EFS by actually decrypting it straight out because their cert was deployed (e.g. GPO) so it was used to encrypt it along with the user's cert (this would be Data Recovery Agent or DRA).
The other way is that they have Key Recovery Agents (KRA) that are able to restore the archived private key from their internal CA. Of course this requires that key archival be turned on, but this is a simple checkmark in the certificate template that is set. Once the key is recovered, that can be used to recover whatever the cert was protecting.
So using BitLocker (native option to vista/2008) or other whole disk encryption like WinMagic, you can use a cert to encrypt your whole hard drive. This gives the security that a stolen laptop, hard drive, etc. cannot be read even to the point of booting to the OS. This is a good thing in stolen property scenarios.
Using PKI for this cert instead of a self-signed cert means you can have your KRA recover the key so that you can decrypt the data when the employee leaves, is suspected of various illegal things or breaking company policy, or if they simply loose their PIN or the cert gets corrupt.
Properly, this cert should be stored on a smart card or on a TPM (trusted platform module) chip on the motherboad. This provides physical protection of the certificate's private key. However, sometimes this may be stored in an unprotected area of the hard drive to pre-boot it to access the cert - this will usually be protected by syncronous encryption using a password - or will just use synchronous encryption throughout and skip the cert.
This could be a self-signed certificate, in which no PKI is needed. This might be fine for a home user - although they are more likely to never back up that key and make all of their data unrecoverable.
In the business world, encryption is a touchy subject. One the one hand, you need to protect your data - so you need encryption. On the other hand, you need to be able to recover all the data that belongs to your organization and for other legal needs, so encryption gets in the way.
A properly set up PKI will have recovery agent certificates set up for various encryption certificates. These do not affect signing-only certificates. This allows a restricted couple of people (usually only one or two people, even in large organizations there are just a few) to decrypt the encrypted data. This may be done like in EFS by actually decrypting it straight out because their cert was deployed (e.g. GPO) so it was used to encrypt it along with the user's cert (this would be Data Recovery Agent or DRA).
The other way is that they have Key Recovery Agents (KRA) that are able to restore the archived private key from their internal CA. Of course this requires that key archival be turned on, but this is a simple checkmark in the certificate template that is set. Once the key is recovered, that can be used to recover whatever the cert was protecting.
So using BitLocker (native option to vista/2008) or other whole disk encryption like WinMagic, you can use a cert to encrypt your whole hard drive. This gives the security that a stolen laptop, hard drive, etc. cannot be read even to the point of booting to the OS. This is a good thing in stolen property scenarios.
Using PKI for this cert instead of a self-signed cert means you can have your KRA recover the key so that you can decrypt the data when the employee leaves, is suspected of various illegal things or breaking company policy, or if they simply loose their PIN or the cert gets corrupt.
Properly, this cert should be stored on a smart card or on a TPM (trusted platform module) chip on the motherboad. This provides physical protection of the certificate's private key. However, sometimes this may be stored in an unprotected area of the hard drive to pre-boot it to access the cert - this will usually be protected by syncronous encryption using a password - or will just use synchronous encryption throughout and skip the cert.
Real world examples for PKI:
Authentication/validation (signing):
- Identity cards - a number of governments are requiring certs on ID cards as the physical card can be replicated - the cert cannot.
- Validating servers - the cert is signed by a trusted CA that you trust, so you validate you are talking to the correct server. If a site was being redirected, then they would not have the cert. This is for web servers and internal use, say for database replication - you want to make sure you are sending your SQL data to a legit box!
- Validating visitors - "client certificate authorization" is used to issue a cert from your PKI to your customers or employees when they access a resource, typically a web site. Passwords can be hacked - certs are much more difficult. Also can use certs for VPN authentication.
- Workstation logon - here is one of your AD things - use a smartcard cert to logon instead of a password. Much more secure. From a low level sense, it is also a straighter shot to Kerberos than password based authentication, but I won't get into that.
- Document signing - prooves that the document was unmodified and signed by the person who signed it. When using a certificate the properly asserts the 'non-repudiation' bit it has legal significance just like a handwritten signature. Note that just having that bit set doesn't mean that your CA is supposed to allow it - if your PKI isn't independently audited it won't hold water in court. Yes, many lawmakers sign bills with their smart card.
- Email signing - shows the recipient that you actually sent that email and that it wasn't intercepted and modified. See above note about non-repudiation - applies here too.
- Machine authentiction - domain controllers, workstations, networking devices, etc. can be authenticated to be allowed onto the network.
Data Security (encryption):
- Securing data in transit (e.g. web server traffic, replication, etc.) - used to initiate SSL connections to protect your banking info, passwords, etc. or IPSec tunnels for replication traffic.
- Encrypting local data at rest (e.g. files on your hard drive) - EFS, bitlocker, zip files, etc. can all be used for various file encryption to protect it from being read when it is being store on your hard drive, tapes, etc. Protect password files, archives, sensitive data, trade secrets, SOX compliance, HIPAA compliance, PCI DSS compliance, etc.
there's a ton more... PKI is security. Anything else that is involved in security, when propertly set up, should include PKI - your firewall, your domain controller, your logon, everything.
More on AD - If a windows CA is set up as an Enterprise CA, this means it will be part of AD and is normally an Enterprise Admin level job. A whole new section is created in AD - view AD Sites and Services - View - Show Services Node. If there is an enterprise PKI then there will be a public key services area there. It contains the names of authorized CAs, where CRLs are stored, certificate templates, and so forth.
Authentication/validation (signing):
- Identity cards - a number of governments are requiring certs on ID cards as the physical card can be replicated - the cert cannot.
- Validating servers - the cert is signed by a trusted CA that you trust, so you validate you are talking to the correct server. If a site was being redirected, then they would not have the cert. This is for web servers and internal use, say for database replication - you want to make sure you are sending your SQL data to a legit box!
- Validating visitors - "client certificate authorization" is used to issue a cert from your PKI to your customers or employees when they access a resource, typically a web site. Passwords can be hacked - certs are much more difficult. Also can use certs for VPN authentication.
- Workstation logon - here is one of your AD things - use a smartcard cert to logon instead of a password. Much more secure. From a low level sense, it is also a straighter shot to Kerberos than password based authentication, but I won't get into that.
- Document signing - prooves that the document was unmodified and signed by the person who signed it. When using a certificate the properly asserts the 'non-repudiation' bit it has legal significance just like a handwritten signature. Note that just having that bit set doesn't mean that your CA is supposed to allow it - if your PKI isn't independently audited it won't hold water in court. Yes, many lawmakers sign bills with their smart card.
- Email signing - shows the recipient that you actually sent that email and that it wasn't intercepted and modified. See above note about non-repudiation - applies here too.
- Machine authentiction - domain controllers, workstations, networking devices, etc. can be authenticated to be allowed onto the network.
Data Security (encryption):
- Securing data in transit (e.g. web server traffic, replication, etc.) - used to initiate SSL connections to protect your banking info, passwords, etc. or IPSec tunnels for replication traffic.
- Encrypting local data at rest (e.g. files on your hard drive) - EFS, bitlocker, zip files, etc. can all be used for various file encryption to protect it from being read when it is being store on your hard drive, tapes, etc. Protect password files, archives, sensitive data, trade secrets, SOX compliance, HIPAA compliance, PCI DSS compliance, etc.
there's a ton more... PKI is security. Anything else that is involved in security, when propertly set up, should include PKI - your firewall, your domain controller, your logon, everything.
More on AD - If a windows CA is set up as an Enterprise CA, this means it will be part of AD and is normally an Enterprise Admin level job. A whole new section is created in AD - view AD Sites and Services - View - Show Services Node. If there is an enterprise PKI then there will be a public key services area there. It contains the names of authorized CAs, where CRLs are stored, certificate templates, and so forth.
ASKER
Thank you for the help and patience. I now realize that the certificates can be applied both through a manual process that involves a live person, or can also be applied through an application interface, like a secure web portal or through AD.
If being applied through Active Directory, is a schema change required? I assume that a schema change will be necessary in order to create an attribute that handles certificates? Also, do you know if the certificate can be created and applied to an AD object through a group policy?
This will pretty much cover my curiosity. Thanks again for the assistance.
If being applied through Active Directory, is a schema change required? I assume that a schema change will be necessary in order to create an attribute that handles certificates? Also, do you know if the certificate can be created and applied to an AD object through a group policy?
This will pretty much cover my curiosity. Thanks again for the assistance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wow, thank you very much Paranormastic. Your examples and explanations are invaluable. Really appreciate it.
PKI is useful when you want to be able to authenticate a message from user to multiple users,
EG: Company holds private key and send public key for clients.
Company sends message to client signed by private key. Clients get ensure that the message came from Company.
And in reverse, to encrypt a message from Client to Compnay.
Message is sent from Client to Company, only the company can receive it.
I'm sure you can think of a few applications where you wouldn't want anyone to listen/see what you were doing.