Официален блог на WebEKM EKM очаквайте сайта онлайн скоро.
Download Free Templates http://bigtheme.net/ free full Wordpress, Joomla, Mgento - premium themes.
Public Key Infrastructure
secure connection through unsecured network
Simple RSA Private/Public key is not enough to provide secure connection between Client and Server. How do we really know that the server we want connect to is actually correct server, not a bogus one ? Private Key might be stolen and somebody else can easily pretend the server. 3rd party Certificate Authority and Public Key Infrastructure is the answer.
Public Key Infrastructure is a mechanism for providing secure communication in an unsecured network.The key aspect of PKI is Certificate Authority (CA), institution which provides Digital Certificate for us, which makes us sure that the server we want connect to is trustworthy. Certificate may be also issued by a router that we want connect to (self-signed certificate) and then has to be manually installed on each client machine. As you see this solution is not scalable. So for company that has a lot of clients, customers (e- commerce) etc the best solution is external Certificate Authority. We may also run our own Certificate Authority. This possibility gives us Windows 2012 (Active Directory Certificate Service role) but rather only within common domain.
How PKI works ?
Firstly we need to know how Private/Public key pair works. Private/Public key is asymmetric type of encryption what means, If we encrypts something with Private Key it may be only decrypted with Public Key and inversly. So each site of connection need both keys for encryption and decryption, but only Public keys are being sent through the network. Private keys are always stored on machines and never are being sent ! This pair of keys is generated every time when we need to establish secured connection. Sender is asking about Public Key. Receiver generates Public/Private Key especially for this conversation and sends back the Public Key. Sender encrypts message with obtained Public Key and sends its to the Receiver. Only Receiver can decrypt the message because only he has the Private Key generated earlier ! Take a look at the picture below.
Let’s check on the example. The Bank’s Client wants to establish secure connection with https://www.bank.com using SSL.
There is a couple of steps which have to be fulfilled in order to provide PKI and authenticate client/server successfully.
1. We need to be sure, on our “HTTPS Server” we have correct time. In order to keep clock and date always up to date we may use Network Time Protocol or even use external physical NTP server.
2. “HTTPS Server” downloads CA Root Certificate (if doesn’t have already) which authenticates CA and ensures us that we have to deal with real CA. This certificate may be checked and confirmed by the phone. When we once trust CA Root Certificate our device will be trusting each certificate issued by this CA.
3. “HTTPS Server” generates its own Public and Private Key and sends to Certificate Authority a CSR (Certificate Signing Request). This CSR contains: Public Key and Attributes for the requester identity (CN,ALT name etc). CSR is always in PKCS#10 format (binary or base64)
4. CA signs “HTTPS Server” Public Key with its own Private Key (Digital signature -HASH encrypted with Private Key) and sends it back to “HTTPS Server”. This is the Identity Certificate. Public Key and Private Key represents a pair. If something has been encrypted with Private key, might be only decrypted with Public Key and vice versa.
5.This Identity Certificate also known as Digital Certificate is being sent to Client by “HTTPS Server”
6. When Client browser gets Certificate from HTTPS Server then looks into Issuer Name and compares this Certificate Authority with stores Certificate Authority Certificates. If it finds that trusted Certificate Authority then secure connection is being established.
Below Picture shows above situation with marked steps. Please click on to enlarge.
