PKI or Public Key Infrastructure is an architecture introduced to increase the level of security for data exchanged over the Internet. Basically, the term PKI can be defined in two ways, (1) the method, technology and technique used to create a secure data infrastructure, and (2) the use of the public and private key pair to authenticate and to proof the content.
PKI uses a mathematical technique called public key cryptography which uses a pair of related cryptographic keys in order to verify the identity of the sender (through signing) and/or to ensure privacy ( through encryption of data ). PKI has been developed primarily to support and ensure secure data transfer through insecure networks, such as the Internet or through private networks, such as corporate internal networks. The PKI's functions also include the delivery of cryptographic keys between users securely ( also through devices like servers), and to facilitate other cryptographically delivered security services.

What is a public and private key?

When we speak of a public and private key, we are speaking of the involvement of two different kinds of cryptography. The public and private key both have different values, thus meaning that if you know one of them, the possibility of figuring out the other one is very rare as it can't be calculated. The public/private key uses asymmetric cryptography while the secret key uses symmetric cryptography. The reason why the secret key uses symmetric operation is because the same key is used to encrypt and the decrypt the information. The public/private key uses asymmetric operation because one of them is used to encrypt the data and only the other one can be used to decrypt it thus showing why it is asymmetric. With the secret key, neither the sender of the message nor the recipient can be identified because with the secret key, the person can read, edit and create the data whereas the public and private key is totally different. The public key can be given to anyone so that they can encrypt data meant for the public key owner (you) knowing that only you can read the data. If the data is encrypted using your private key and sent to anyone, and if they are able to decrypt the data using the public key you gave them, thus they are able to immediately identify that the data came from you.

How does Public Key Cryptography works ?

Public-key cryptography uses a pair of mathematically related cryptographic keys. This can be seen through the encryption and decryption of data. When data is encrypted using one key, only the related key can decrypt the data and although they are mathematically related, just by knowing one key you cannot calculate the the other one easily as the chances are rare. Thus a public key system ensures that you have (1) a public key that can be distributed freely to anyone and (2) a private key which is secret and is not shared by anyone as it enables you or the original author of the data to prove yourself.

>>The Public Key Encryption Process

When another person wants to send you confidential data, they encrypt the data using your public key. Normally, data is actually encrypted using a secret key algorithm (symmetric cryptography = explained above ) which are much faster than the asymmetric cryptography used by the public and private keys of the user. Thus a random session key is generated using symmetric algorithm to encrypt the data and the public key is then used to encrypt that key and both are sent securely to the recipient.

>>The Private Key Decryption Process

The data which has been encrypted using the public key can be decrypted using its corresponding private key. If the private key is able to decrypt then data sent, then the user is certain that the data is meant for him/her but cannot identify from whom or where the data actually originated from. Normally, the private key will actually decrypt the session key and the decrypted session key is used to decrypt the actual data sent rather than having the private key decrypting the whole data at one go. This is thus more secure as the session key is randomly generated and has to be decrypted first in order to proceed to the next process of decrypting the data.

What is a digital signature ?

A digital signature is a unique encrypted numerical value. A digital signature differs each time it is generated and is mainly used in relation to signing documents of data, picture software and so on thus proving the ownership or copyright of the data. It is created by performing a mathematical calculation using a 'hashing' or 'message authentication' algorithm, on the document to be signed (thus showing why it differs each time it is generated) and producing a unique numerical value which is then encrypted using a private cryptographic key and then links the results to the document which it signs. This shows that in order to create a digital signature, a private cryptographic key and a corresponding public key and certificate must be generated or bought. In a digital signature, the receiver is the person who actually sets the rules for the signature. Even though the security mechanism(s) in any system is set by the sender but the actual recipient of the data is the one who decides what to do, what to believe, what to trust. So it is clear that no matter what is claimed in a certificate, the decision fully lies in the hand of the recipient. This decision can vary be it about access control or authorization, it is the recipient's responsibility to consider all the data available to them in order to aid them in making the decision and taking action. In some countries and regions (the European economic area, the USA, the state of Utah), there are laws that specifically recognize digital signatures. * Adding a digital signature to data DOES NOT provide confidentiality.*

>>Using a Private Key for Signature

If someone wishes to take responsibility or claim over the data sent, thus proving they are the source of the data, they use a private key to digitally sign the data withg a message. This digital signature as explained above is different each time it is generated and is a unique mathematical value calculated using the 'hashing' or 'message authentication' algorithm, which is fully dependent on the message, thus clearly explaining why it is different each time it is generated. This encrypted value is sent either at the end of the data or as a separate file with the message. The corresponding public key may also be sent together, either on its own or as a certificate. Digitally signing a document does not prove anonymity because anyone receiving the protected or digitally signed data can easily check the signature and read and process the data, thus showing why it does not ensure confidentiality.

>>Using a Public Key for Signature

When a digitally signed document reaches the receiver, he/she is able to use the correct public key to verify the signature by following these steps:

(1) The correct public key is used by the receiver to decrypt the hash value which was calculated by the sender for the data.

(2) Then, using the 'hashing' algorithm, the hash value of the data received is calculated.

(3) The newly calculated hash value is then compared to the hash value which was originally calculated by the sender ( this hash value was calculated at (1) ). If the values of the two calculated hashes are the same, the receiver then knows that the data was sent originally by the owner of the private key and the data has not been edited since it was digitally signed.

(4) If a public key certificate was sent together with the data, it is then validated with the CA that issued the certificate to ensure that the certificate is true and has not been falsified or tampered with and therefore confirming the identity of the controller of the private key.

(5) Finally, the certificate is checked with the revocation list of the Certification Authority (CA) to ensure that the certificate has not been revoked, or if it has , when was it done and at what time was it performed.

The summary of the above information is as follows. If for instance, you receive a document ( say a .doc file) through e-mail. This document was signed by the sender by calculating a has value for the document and has encrypted that value with their private key. You then calculate a hash value for the same document which you received and decrypt the encrypted hash value sent by the sender and compare both the values. If the both values are the same, then you know that the document you have received was sent by who and that the document has not been edited by anyone else. If you find out otherwise, which is the two hash values don't match, then you can be certain that the document has been edited or that the sender is not who they claim to be.

If you wish to encrypt data for your own viewing later, you must use your own public key as the recipient key (because you are the one who is going to view it later, if you use another's public key, only the owner of that key will be able to decrypt and view the data). In order to avoid problem later concerning in ability to read encrypted messages, if you are not the recipient, some systems create a contingency or System Recovery plan by (1) not deleting the original message after it has been encrypted, or (2) storing a copy of the key which was used for encryption under the sender's public key or under the System Recovery key. These methods are called key escrow or key recovery.

Thus Public Key Cryptography is a form of encryption/decryption and signing/verification of data. By encrypting data, further privacy is ensured between the sender and receiver of the data by directly preventing unintended disclosure of the data and also further ensures the sender of the data by authentication and ensures that the data has not been modified or tampered with and is coming directly from the source. Although so, we must have in mind that only data that has been encrypted is secure and protected compared to e-mail systems headers, addresses and body messages which offer no form of protection at all and must never be considered secure.

What is a digital certificate ?

A digital certificate is a digital document which binds your public key to an identity that the issuing Certification Authority (CA) is willing to vouch for. Users of the popular encryption software Pretty Good Privacy (PGP) has the ability to generate their own digital certificates. These certificates are called self-signed certificates because it is signed by the user of the software him/herself and does not need to go to a separate identity certifying authority like the government, post-office, international chamber of commerce, etc etc in order to certify that their identity is valid.

If you happen to be a non-PGP user, then you will have to approach one of the Certification Authority (CA) in order to validate your identity. A good starting point to obtain various list of this authorities is to visit http://www.pki-page.org . This website lists a large number of authorities and has lots of PKI information. Digital certificates such as personal and server certificates have a lifespan of about a year but this actually depends on the issuing CA who can actually determine the lifespan of the certificate. This allows them to have validity dates, and can be either temporarily or permanently revoked. The revocation is the responsibility of the user, just as it is with credit cards. The issuer deals with the validity of the dates of the certificates.

A digital certificate issued by one of the public CA's will contain information in the key usage field of the certificate. This means that the private key which matches the public key in the certificate may be used for specific purposes such as digital signatures, non-repudation, key encipherment, key agreement, data encipherment, certificate signing, CRL signing, encipher or decipher only, etc. These are the set to the values that the issuing CA grants under its licensing terms but if you have issued the certificate by yourself (self-signed), then you have the authority to give yourself any authority over the certificate. Although key usage may be set in the certificate but this does not ensure that the software which uses the public key has done any checks on the content of the certificate as the private key and certificate are two separate files stored in two separate places in the system. Thus meaning that someone receiving a digitally signed document needs to check in the certificate if the key was actually authorized for the type of signature perform. Usually, there are many situations where no check is carried out on the certificate. Signing on to a server or making an SSL connection are two cases in point. When explanation on the public and private keys above was done, there were references made to digital certificates (thus leading my explanation on what is a digital certificate).

The data found in a certificate usually conforms to the ITU (IETF) standard X.509v3. The certificates which conform to this standard includes information about the identity of the owner of the corresponding private key, the length of the key, the algorithm used by the key, and the associated hashing algorithm, also dates of validity of the certificate and the actions whereby which the key can be used for. A digital certificate is not actually an essential for a PKI operation, however, the X.509 certificate serves as the most commonly implemented scheme used to locate data about the controller of the private key.

Who are these Certification Authorities ?

If you go through your browser's settings, you will be able to see a number of certificate recognized by it and eventually find the list of signing authorities recognized by your browser's company be it Microsoft, Netscape, Opera, or Mozilla for that matter. They do not have official recognition as in government agencies. Even financial services such as SWIFT uses a CA structure. Banks invest tonnes of money in a service called Identrus, which is expected to provide the banking CA infrastructure. Some major banks even invest on their own CAs to control internal and customer transaction as well.

Storage of Public and Private Key

>>In a Certificate

A digital certificate is used to store the public key along with other relevant data such as user information, expiration date, usage,the issuer of the certificate, etc. These data is entered by the CA within the certificate and cannot be changed or modified. Since the certificate is digitally signed and the data in it is intended to be publicly viewed, there is no need to prevent access to it, although the owner should prevent other users from corrupting, replacing, or deleting it.

>> Protection and Its Necessity

If someone manages to gain access to your computer, they can thus easily gain unrestrained access to your private key(s), and this could prove to be very dangerous indeed. So in order to add protection against these kind of situation, the private key(s) is generally protected by a password of your choice, thus adding protection to a already protected key making it more secure. These passwords should never be given away and should comply with the secure password ruling if possible, that is to have a password longer than eight characters, should be a mixture of numbers and uppercase and lowercase alphabets. This gives the cracker a harder time to figure out your password and it can't be easily revealed as most password revealing utilities out there can only crack up to an eight character password. Due to this fact, different vendors use different and sometimes proprietary storage formats to further secure the key. For example, Entrust uses the proprietary .epf format, while Verisign, Globalsign, and Baltimore, to name a few, uses the standard .p12 format.

The Components of a Public Key Infrastructure

(1) Certification Authority (CA)

A CA serves as the issuer and verifier of a digital certificate ( a more detailed explanation has been give above). They take responsibility to identify up to a certain extent the pureness and correctness of the user who asked for the certificate, and ensures taht the data provided within a digital certificate is correct and then proceeds to sign it. A public and private key pair is either generated by the CA or the user him/herself and send a signed request containing their public key to the CA to be validated. Usually the person who is applying for the certificate will generate his or her own key pair as to ensure more security and that the private key does not leave their control. As a result, the private key is less available to anyone especially crackers. Even so, this is only if you apply for a certificate through a CA. If the certificate is generated by yourself using certain application software like PGP, you will not have to buy a certificate from the CA. If you are buying one from a CA, then you must be aware that the CA will perform various checks to prove that you are who you claim to be for security reasons. Once they have confirmed your identity, they will then input this data and digitally sign your certificate so as to prevent modification or tampering of the data by other users. They may also state the quality of the checks that they carried out before issuing you the certificate.

Certificates of different classes which corresponds to the level of checks made can be purchased. Class 1 certificates can be easily obtained just by providing an e-mail address, whereas Class 2 certificates can only be obtained if additional personal information is provided. A Class 3 certificate requires checks to be made to the identity of the purchaser and a Class 4 certificate is basically used by governments and organizations thus clearly showing that the checking done is very much more high leveled. An individual is not restricted to the number of certificates he/she can have. This is because different web applications sometimes insists on the user using certificates issued by certain CA's only. The CA in this case may be a unit within your organization, a company (bank, post-office), or even an independent entity such as Verisign for instance. The public key certificate is digitally signed by the CA so as to prevent modification or falsification by other users, and to check if the public key is still valid. The digital signature is validated against a list of "Root CA's" which are contained within various 'PKI aware' applications like a browser for instance.

Some certificates are called 'Root Certificates' because they form the root of all certificate validation. Certificate validation occurs automatically using the appropriate public certificate contained within the root CA list. Even so, users of the PGP software, normally act as their own issuing authority, thus meaning that you accept the certificate knowing who they are and believing who they claim to be without further verification. This method is called the "Web of trust" as it is based on people whom you trust rather than liability contract.

(2) Revocation

Revocation is basically the process of deleting a certificate from the Directory. If the certificate has been deleted from the library, attempts to check if they still exist will fail thus clearly showing the user who is searching for them that the certificate has been revoked. The main problem concerning this approach is that if a Denial of Service attack on the directory was performed, then it would seem as if the certificate has been deleted thus confusing the owner of the certificate if their certificate is still valid or not. Another problem encountered by this approach is that the Directory was initially designed to optimize the time to read information, and the act of deleting or updating is normally avoided. Besides that, deleting the record of the certificate does not tell the user searching for the information when it was actually deleted. Due to this problem, a system of revocation lists has been developed. This system exists outside the Directory or database and contains the list of certificates that are no longer valid. The two methods of checking if a certificate has been revocated would be through 'CRL' or 'OSCP'. Revocation lists are publicly available although the matching Directory or database is not. This is due to the fact that the certificates may have been distributed for use beyond the private network of the organization involved.

(3) Registration Authority (RA)

A Registration Authority (RA) is a third-party used by the CA to perform necessary checks on the person or company which is applying for the certificate to ensure that they are who they claim to be. RA's may appear to the requestor of the certificate as CA's but they don't digitally sign the certificate.

(4) Certificate Publishing Methods

One of the main fundamentals in PKI systems is the publishing of a certificate so that other users can find these certificates. There are two main ways of doing this. Publishing of a certificate can be done either by publishing it in the equivalent of an electronic telephone directory and the other way is to send it to people who you think might need it by one means or another. The commonest approaches are as follows :

>>Directories

Directories are basically databases that are X.500/LDAP-compliant. This basically means that the databases contain certificates in the X.509 format, and that they provide specific search facilities which are specified in the LDAP standards published by the IETF. Directories or databases can either be publicly available or remain in a private network belonging to a specific organization. Private Directories usually contain confidential data that the owner does not wish to be publicly accessible. Public directories on the other hand contains information which can be read by anyone with access to them.

>> Databases

Databases can be configured to accept X.509 format certificates thus making it X.500/LDAP-compliant. This can be done for private systems where search methods do not follow the LDAP structure. This method is not used for public directories because it is essentially proprietary.

>>E-mail, floppy discs, cd's, etc.

Certificates can also be sent through e-mail so that the recipient can add them to their server or desktop, depending on how their security systems are configured. Certificates can also be carried in floppy discs, or any other medium available.

(5) Certificate Management System

Certificate Management Systems are basically systems whereby which certificates are published, temporarily or permanently suspended, renewed or revoked. These systems do not normally delete certificates because it may be a necessity to prove their status in the future, probably for legal reasons. A CA and maybe a RA will run these systems to keep track of their responsibilities and liabilities towards their clients.

(6) 'PKI-aware' applications

These applications are those that have had a particular CA software supplier's toolkit added to them thus enabling them to use the supplier's CA and certificates to implement PKI functions. Although so, this does not mean that these applications have any knowledge base built in to them about what the security requirements really are, or which PKI services are relevant in their delivery. These are separate issues from having PKI services available.

The Benefits of PKI

1. Users have a certainty of the quality of data sent and received electronically.
2. They have assurance of the source and destination of the data.
3. Users also have the assurance of the time and timing of the data provided the source of time is known.
4. They have certainty of the privacy of that data.
5. They also have the assurance that the information may be introduced as evidence in a court of law.

The Risks of Using PKI

1. The word 'trust' is often used when PKI and a CA is concerned ( who gave the CA such authorization and made it trusted).
2. How to protect your own private signing key even though it is encrypted and password protected ?
3. How secure is the computer verifying the key ?
4. A CA model is much more secure compared to a CA+RA model.

and many, many more coming in the next tutorial on PKI...

If you have any comments on the above tutorial, please e-mail me at jagganatha@hotmail.com. These tutorial was written by myself after reading some other papers on PKI. If some words or sentences from other sources are repeated here, then please forgive me because this tutorial was directly written after reading those papers resulting in some repetitions. Any errors are greatly regretted.

THANKS A MILLION TO SHAOLIN TIGER FOR YOUR SUPPORT !!

Admin Note: Please be advised that jaggantha has changed his member account to neobloodline, and all Private Messages and inquiries should be addressed to the later. ---PCWriter

First of all congracts on your first paper. Please take the below as constructive criticism This paper is good for a 17yr old. The paper is fitting in most circumstances although PKI could have been explained much elaborately. Some experience in implementation would have helped much more.

A much clearer explanation of Cryptographic algorithms would have helped you to elaborate about key lengths and factoring primes.

There is inadequate explanation regarding X.509v3.

Key Escrow is mostly a TTP key storage facility (Can be termed as Facility) which might use M&N technique.

You could have explained with much ease after understanding the C.I.A. Triad. Most of the class 3 PKI Certificates are now spanning to 5 years.
The rest is good. This is a good Start.

The first main benefit of PKI is that it is accepted as an infrastructure. It is merely a secure architecture of distributing keys.
When all the good men came up with steganography & Cryptography, they did not plan for the key distribution process. So this is where PKI fits.

(Try to find this out. Why don't people trust DES & why does the US govt. insist on DES only for all int. communications)

PS. Itís not good to have hacking as your hobby.http://www27.brinkster.com/jagganatha/about.html

Thanks for the comments. Will work on it. The website you say is very old. I have to do some serious updating on it. But I think my hobby as hacking will always remain. Ha ha. Anyway thanks again for the comments.

I am a junior college student currently in my thesis year. The topics of my thesis are cryptography and steganography. My proposed application will try to encrypt files, hide them in an image and send them to different receivers. However, each receiver will have to enter their own keys to extract the files intended only for them.

Generally, files embedded in the image can only be extracted/decrypted by users who are the intended recipients of the files. In line with this, I would like to ask something about the public-key infrastructure (PKI).

Is there a public-key cryptography that enables a sender to send a message, by encrypting the data using the public keys of 2 or more users, and then, the receivers can then decrypt the cipher using their "own" private keys?

It may sound like a secret sharing scheme, but the receivers of the cipher uses different keys to decrypt the message.

Am I correct in that a single file can go to multiple recipients, and each recipient may have multiple files?
Are all of these files then being hidden in the same image file? and then this same image file being sent to all the recipients?

If so, the amount of data that you would have to hide would probably be too large to realistically fit in a single image without being noticeable. I also don't see a problem with encrypting the same data twice with different keys, so each recipient may have a copy.

These are just a few initial thoughts, and any other questions or comments would be appreciated.

Cheers,
Martin

Mods: Might be worth spinning this conversation out to a separate topic.

I have to agree.. a more efficient way would be to encrypt the data separately for each user. Yes it is a little tedious but it is much more effective and efficient in relation to what mxb said about space on disk...

sorry I didn reply to this earlier..my browser crashed some time ago and I think it was while I was surfing Secuity-Forums so I would have missed the notice that someone posted a reply to this topic..

Am I correct in that a single file can go to multiple recipients, and each recipient may have multiple files? Are all of these files then being hidden in the same image file? and then this same image file being sent to all the recipients?

Yes. Multiple files will be hidden in just a single image (carrier image), that will then be sent to multiple recipients.

However, the size of all the files combined should be less than or equal to the capacity of the image (currently, I am studying on the properties of a pixel; the difference of a couple of manipulated bits with respect to the original value of the pixel).

I agree that it would be very easy to group files that are intended for a specific user and then encrypt them. But what if a file is intended for two users? This will cause a redundancy when I will embed it in the target user. Embedding the file twice will be redundant, and it will also decrease the amount of "space" the carrier image can handle.

Thank you for replying and I hope I have clarified my idea.

Last edited by toffet99 on Thu Mar 17, 2005 2:47 am; edited 1 time in total

About your statement, I know that it is more effective to embed the file twice. But I don't think it would be efficient, since you have to encrypt the file/s with separate keys and then embed them in an image more than once. As I said earlier, it would be redundant and the capacity of the image, as a carrier, will lessen; thus, less files will be embedded

Well yeah maybe I was a llittle wrong in the efficient part because it was dealing with the same info for multiple users if I am not mistaken. Maybe I should have said efficient encyption or something coz you save disk space of the users and the image file for instance not being too big and suspicious as mxb mentioned...it was my mistake.. apologies on the wrong language used..

OK My mistake, I jst read ur post to mxb..if you are able to ensure that it doesn get too suspicious as you said, then yes I have to agree on redundancy for just 2 users..

Only very quickly skimmed through the article...seemed alright to me.
The hardest thing is getting people to read stuff like that, which in my opinion should be standard knowledge among anyone who claims to "be good with computers".

As for sending the same file to multiple recipients using PKI, go read the OpenPGP RFC, its simple enough. Just encrypt the random session key to each different public key.
Yes, it takes up a wee bit more space, but lets be realistic, we're talking sub kilobyte sizes - who cares.
Of course, when one is trying to smuggle crap in jpegs then you might (though I think trying to hide things in jpegs is a bit of a challenge, its not the simplest image format is it?).
Though you merely said images so I figure you'll be thinking about bitmap's first, which should be less hard.

You'll be able to find plenty of GPL'ed code relating to cryptography and to a much lesser degree steganography. They do teach you not to reinvent the wheel, right?

thanks a lot guys...i've got a lot more questions to ask, but for now, i really appreciate your help...

hope you do reply to my succeeding questions and queries...

if it's not to much to ask, may i know your names, positions/job description, company/school and contact details...i would like to add you as my resource persons...if you can, please email me at gundamw_deathscythe_hell@yahoo.com...

I have a question regarding certification. Perhaps it has already been explained implicitly above.

Let us assume we are using any of the standards mentioned above. Suppose Alice wants to make use of the system. She generates a public-private keypair (u, v). Let u be public trey and v be the private key. the CA certifies the pair (u,"Alice").

My question is how does the CA know that Alice indeed knows the corresponding private key v. Does Alice also give a "zero-knowledge" proof of v when requesting a certifiable?

As such it does not seem to be a problem but I suspect various CCA attacks may exist if this verification is not done. Any feedback?

Regarding the question of toffet99 about having two public key for one message, a (t, n) threshold scheme would suffice with t=1 and n=2.