Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
If want to give someone access to a server via ssh should I create the pair and send them the private key or should I have them create the pair and send me the public key?
The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key, but anybody who has your public key can verify that a particular signature is genuine. That is how server authentication protocols are currently implemented. The server sends a snippet of random data that your client then signs and returns to the server. The server uses your public key to verify the signature.
Note that if the server side has no independent means of knowing that your public key comes from you, then you could use a digital cert signed by a trusted third party to validate the pubic key. Most sys admins don't go this far when setting up authenticated logins manually, but a personal cert is sometimes required for financial systems. Search "PKI".
If the server side generates the key pair, then you would need a way to securely transmit that key pair to an authenticated client, then destroy the private key on the server side.
I would be possible to set up a client authentication system with the private key on the server side and the public key on the client side. The authentication protocol would be that the server would send a random snippet to the client for encryption and the client would return the encrypted snippet to the server. The client would have to secure the public key against compromise, and it would only be good for one server, whereas when the private key is on the client side the client can use the same public key for authentication against multiple servers.
Definitively the second, they should generate the private key and send you the public one, that way you don't send the private key over the wire.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Update: reading itext whitepaper on using smart cards to sign and have the following question:
Digital signatures in a smart card: Why have two certificates, one for authentication and the other for non-repudiation? Why can't one certificate be used for both since both authentication and non-repudiation certificates uses private keys to encrypt and public key to decrypt. Is it because the "authentication certificate" contains sensitive info?
It's said that the authentication signatures allows the card to prove his identity and also the certificate contains privacy-sensitive information such as gender, date of birth, and national number. The non-repudiation signature is used for to generate electronic signatures.
It is common practice to have multiple keys for multiple purposes.
There may be a lot of technical differences and procedural differences:
Authentication could have the PIN cached while the private key of the non-repudiation (non-rep) certificate could require a PIN to be supplied by the holder for each signature operation.
One private key could be revoked (e.g. the more sensitive non-rep key) while the authentication key could still be be used.
Authentication maybe used for longer than the non-rep key.
The key usage of the non-rep key could be more strict.
The CA keys of the non-rep key could also have a higher grade of protection.
It used to be the case that e.g. SSL authentication required different signature (MD5 + SHA-1) or encryption operations. The higher the access to keys, the less secure they will be. Nowadays TLS can be used to have a more regular signature in combination with ephemeral Diffie-Hellman.
As Eugene has commented, there may be legislature in place that requires separate keys and/or certificate chains for authentication and non-rep.
Even if all the above are not true yet, they may apply in the future. Hence the specific keys for a specific purpose. And note that the above is just out of the top of my head.
I have three questions regarding SSL that I don't fully understand.
If I get it correctly, a server A submits a request to a certain CA. Then, it receives (after validation etc.) a digital certificate composed of a public key + identity + an encription of this information using the CA's private key.
Later on, a client B wants to open an SSL communication with A, so A sends B its digital certificate.
My question is can't B just take this certificate, thus stealing the identity A - which will allow them to authenticate as A to C, for example. I understand that C will decrypt the certificate with the CA's public key, It will then encrypt its symetric key which will only be decryptable by the real A.
However, I do not see where authentication comes to play if B can actually steal A's identity. Unless I am missing something.
Second question: Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
Thank you very much.
An SSL identity is characterized by four parts:
A private key, which is not shared with anyone.
A public key, which you can share with anyone.
The private and public key form a matched pair: anything you encrypt with one can be decrypted with the other, but you cannot decrypt something encrypted with the public key without the private key or vice versa. This is genuine mathematical magic.
Metadata attached to the public key that state who it is talking about. For a server key, this would identify the DNS name of the service that is being secured (among other things). Other data in here includes things like the intended uses (mainly used to limit the amount of damage that someone with a stolen certificate can do) and an expiry date (to limit how long a stolen certificate can be used for).
A digital signature on the combination of public key and metadata so that they can't be messed around with and so that someone else can know how much to trust the metadata. There are multiple ways to handle who does the signature:
Signing with the private key (from part 1, above); a self-signed certificate. Anyone can do this but it doesn't convey much trust (precisely because anyone can do this).
Getting a group of people who trust each other to vouch for you by signing the certificate; a web-of-trust (so called because the trust relationship is transitive and often symmetric as people sign each others certificates).
Getting a trusted third party to do the signing; a certificate authority (CA). The identity of the CA is guaranteed by another higher-level CA in a trust chain back to some root authority that “everyone” trusts (i.e., there's a list built into your SSL library, which it's possible to update at deployment time).
There's no basic technical difference between the three types of authorities above, but the nature of the trust people put in them is extremely variable. The details of why this is would require a very long answer indeed!
Items 2–4 are what comprises the digital certificate.
When the client, B, starts the SSL protocol with the server, A, the server's digital certificate is communicated to B as part of the protocol. A's private key is not sent, but because B can successfully decrypt a message sent by the other end with the public key in the digital certificate, B can know that A has the private key that matches. B can then look at the metadata in the certificate and see that the other end claims to be A, and can examine the signature to see how much to trust that assertion; if the metadata is signed by an authority that B trusts (directly or indirectly) then B can trust that the other end has A's SSL identity. If that identity is the one that they were expecting (i.e., they wanted to talk to A: in practice, this is done by comparing the DNS name in the certificate with the name that they used when looking up the server address) then they can know that they have a secured communications channel: they're good to go.
B can't impersonate A with that information though: B doesn't get A's private key and so it would all fall apart at the first stage of verification. In order for some third party to impersonate B, they need to have (at least) two of:
The private key. The owner of the identity needs to take care to stop this from happening, but it is ultimately in their hands.
A trusted authority that makes false statements. There's occasional weaknesses here — a self-signed authority is never very trustworthy, a web of trust runs into problems because trust is an awkward thing to handle transitively, and some CAs are thoroughly unscrupulous and others too inclined to not exclude the scum — but mostly this works fairly well because most parties are keen to not cause problems, often for financial reasons.
A way to poison DNS so that the target believes a different server is really the one being impersonated. Without DNSsec this is somewhat easy unfortunately, but this particular problem is being reduced.
As to your other questions…
Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
While keys are fairly long, certificates are longer (for one thing, they include the signers public key anyway, which is typically the same length the key being signed). Hashing is part of the general algorithm for signing documents anyway because nobody wants to be restricted to signing only very short things. Given that the algorithm is required, it makes sense to use it for this purpose.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
If you have several servers serving the same DNS name (there's many ways to do this, one of the simplest being round-robin DNS serving) you can put the same identity on each of them. This slightly reduces security, but only very slightly; it's still one service that just happens to be implemented by multiple servers. In theory you could give each one a different identity (though with the same name) but I can't think of any good reason for actually doing it; it's more likely to worry people than the alternative.
Also note that it's possible to have a certificate for more than one service name at once. There are two mechanisms for doing this (adding alternate names to the certificate or using a wildcard in the name in the certificate) but CAs tend to charge quite a lot for signing certificates with them in.
My question is can't "B" just take this certificate, thus stealing the identity of "A" - which will allow them to authenticate as "A" to "C"
There's also a private part of the certificate that does not get transmitted (the private key). Without the private key, B cannot authenticate as A. Similarly, I know your StackOverflow username, but that doens't let me log in as you.
Why use hashing on the certificate if a part of it is already encrypted by the CA?
By doing it this way, anyone can verify that it was the CA who produced the hash, and not someone else. This proves that the certificate was produced by the CA, and thus, the "validation etc." was performed.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
It depends on the particular case, but you will likely have identical certificates on each.
First question: You are correct about what you get back from the CA, but you are missing part of what you need before you submit your request to the CA. You need (1) a certificate request, and (2) the corresponding private key. You do not send the private key as part of the request; you keep it secret on your server. Your signed certificate includes a copy of the corresponding public key. Before any client will believe that B "owns" the certificate, B has to prove it by using the secret key to sign a challenge sent by the client. B cannot do that without A's private key.
Second question: Typical public-key cryptography operates on fixed-size data (e.g., 2048 bits) and is somewhat computationally expensive. So in order to digitally sign an arbitrary-size document, the document is hashed down to a fixed-size block which is then encrypted with the private key.
Third question: You can use a single certificate on multiple servers; you just need the corresponding private key on all servers. (And of course the DNS name used to reach the server must match the CN in the certificate, or the client will likely balk. But having one DNS name refer to multiple servers is a common and simple means of load-balancing.)
In general, yes, if the cert file gets stolen, nothing will stop someone from installing it on their server and suddenly assuming the stolen site's identity. However, unless the thief takes over control of the original site's DNS setup, any requests for the site's URL will still go to the original server, and the thief's server will stay idle.
It's the equivalent of building an exact duplicate of the Statue of Liberty in Antarctica with the expectation of stealing away New York's tourist revenue. Unless you start hacking every single tourist guide book and history textbook to replace "New York" with Antarctica, everyone'll still go to New York to see the real statue and the thief will just have a very big, green, complete idle icicle.
However, when you get a cert from a CA, the cert is password protected and cannot simply be installed in a webserver. Some places will remove the password so the webserver can restart itself without intervention. But a secure site will keep the password in place, which means that any server restarts will kill the site until someone gets to the admin console and enters the PW to decrypt the cert.
Question N°1
can't B just take this certificate [...] which will allow them to authenticate as A to C
This part of the a larger diagram deals with that question.
Mainly : if you only have the public key then you can not establish an SSL connection with any client because you need to exchange a secret key with them and that secret key has to be encrypted using your public key, which is why the client asks for it in the first time. The client is supposed to encrypt the shared secret key with your public key and you are supposed to decrypt it using your private key. Since you don't have the private key, you can't decrypt the secret exchange key, hence you can't establish any SSL communication with any client.
Question N°2
Why use hashing on the certificate if a part of it is already
encrypted by the CA?
This is also answered in the original diagram by the question "what's a signature ?". Basically, we're hashing the whole certificate to be sure that it hasn't been tampered with (data integrity), that nobody has changed anything in it, and that what you see is really what was delivered by the CA. The diagram shows how hasing makes that possible.
Question N°3
If I am stackoverflow and I have 3 servers [...] do I have to have a
different digital certificate for each of the 3 servers.
This is not necessarily always the case. Consider the situation where all three servers are on the same domain, then you only need one certificate, if each of them is on its own subdomain you can have one single wildcard certificate installed on all of them.
On the contrary, if you have one server that hosts multiple domains you would have one single multi-domain SSL certificate.
I also have some answers.
Q1) If B steals A's certificate and try to impersonate as A to C.
C will validate the IP address of B and find out that it does not belong to C. It will then abort the SSL connection. Of course, even if C sends an encrypted message, then only the Real A will be able to decrypt it.
Q2) A certificate is usually represented in plain-text using the common format X.509. All entries are readable by anyone. The hashing process is used to digitally sign a document. Digital signing a certificate makes the end user validate that the certificate has not been altered by anyone after it was created. Hashing and encrypting the content using the issuer's private key is done to create a digital signature.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
and what are the differences between conventional cryptography and public-key cryptography?
You should probably re-phrase your question:
Public-key cryptography uses an asymmetric approach where the key used to encrypt and the key used to decrypt a message are not the same. Here is a description of the RSA asymmetric algorithm: RSA (asymmetric cryptography)
There is probably no "conventional crypthography". What you probably mean are symmetric algorithms where both keys are the same. Symmetric key algorithm
Basically, public-key cryptography means that you have a "public/private" pair of keys. The public key can be used to encrypt messages, but not decrypt them. The private key is, as the name suggests, secret, and can be used to decrypt the messages.
Typical usage goes like this:
Alice creates a public/private key pair.
Alice sends her public key to Bob, keeping the private key in a safe location.
Bob sends the encrypted message to Alice.
Alice receives the message and uses her private key to decrypt it.
Usage examples of asymmetric encryption:
In situations where no trusted channel can be established for exchanging symmetric keys (e.g. HTTPS): because the public key cannot decrypt, it is safe to send it over an untrusted connection
When the same public key needs to be used by more than one user (e.g. encrypted e-mail): even though all the senders use the same public key, they cannot use it to decrypt any messages; only the recipient has the private key
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
What I understand about RSA is that Alice can create a public and a private key combination, and then send the public key over to Bob. And then afterward Bob can encrypt something using the public key and Alice will use the public and private key combo to decrypt it.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
Basically, the procedure is:
The client connects to the server and asks for the server's certificate. The certificate contains the public key and information about the server's identity.
Assuming the client is happy with the server's identity, it generates a random number P and encrypts it with the server's public key.
Only the server can decrypt P (with it's private key - not shared with anybody) so when the client sends the encrypted random number to the server, the server decrypts it.
The client and server both use P to generate a symmetric key for use in a symmetric encryption algorithm, safe in the knowledge that only the client and server know the value of P used to generate the key.
Alice will use the public and private key combo to decrypt it
Alice would just decrypt it with her private key.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it?
Alice would need Bob's public key to send something to him.
Typically, public key encryption is used for authentication, non-repudiation (like signing), and distribution of symmetric keys (which are faster for encrypting/ decrypting long messages).
Simple, you need a key.
SSL/TLS solves this problem by creating a symmetric session key during the connection setup. The public key cryptography is used to establish this session key, which is then used for bi-directional data communication. Read more about TLS
I didn't create this, but someone shared this video with me and it helped the theory make much more sense. As always the devil's in the details (implementation).
http://www.youtube.com/watch?v=YEBfamv-_do
On a general note I struggled to understand Public Key Cryptography for quite a while along with the other elements of PKI such as Digital Signatures and Certificates whilst preparing for Microsoft C# certification.
I came across an explanation in the form of a concise and detailed PDF at cgi.com. I know it's back to good old Alice and Bob! but it really cleared things up for me with its diagrams and notes and also has some thought provoking questions at the end. Definitely recommend it.
Visit http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
This is where you're wrong; you do have a private key. As part of the handshaking process, each side generates two keys: a public key and a private key. The client sends its public key to the server, who will use it to encrypt all data sent to the client. Likewise, the server generates both keys and sends its public key to the client, which will use it to encrypt all data sent to the server.
In many scenarios, the asymmetric key algorithm is used only to exchange another key, which is for a symmetric algorithm.
In this situation, Alice would use Bob's public key to encrypt the data and Bob would then decrypt it with his private key.
Essentially, a public key encrypts data and a private key decrypts that data. Since every user has both a public and private key, you can securely send data to any other user.
If you connect to the site of your bank it works a lot of cryptographic things. The most important is that you use public key of the bank to send a piece of information to the bank, because in every SSL (https) connection server send to client it's public key packed as a certificate.
Usage of certificate and world wide PKI is important. You want be sure, that if you gives to the bank your bank pin, that on the other side is really your bank and not an other person. This will be solved, because on every computers there are a small number of public keys of well known organisations (like VeriSign) and bank send you not only his server public key, but a certificate. certificate is a message signed by VeriSign for example, which say "this public key is really from the bank XYZ". So because you have public key of VeriSign you can first verify, that server certificate of the bank is correct. So you can be sure, that you communicate really with your bank.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I see this word in almost every cross service application these days.
What exactly is an API key and what are its uses?
Also, what is the difference between public and private API keys.
What "exactly" an API key is used for depends very much on who issues it, and what services it's being used for. By and large, however, an API key is the name given to some form of secret token which is submitted alongside web service (or similar) requests in order to identify the origin of the request. The key may be included in some digest of the request content to further verify the origin and to prevent tampering with the values.
Typically, if you can identify the source of a request positively, it acts as a form of authentication, which can lead to access control. For example, you can restrict access to certain API actions based on who's performing the request. For companies which make money from selling such services, it's also a way of tracking who's using the thing for billing purposes. Further still, by blocking a key, you can partially prevent abuse in the case of too-high request volumes.
In general, if you have both a public and a private API key, then it suggests that the keys are themselves a traditional public/private key pair used in some form of asymmetric cryptography, or related, digital signing. These are more secure techniques for positively identifying the source of a request, and additionally, for protecting the request's content from snooping (in addition to tampering).
Very generally speaking:
An API key simply identifies you.
If there is a public/private distinction, then the public key is one that you can distribute to others, to allow them to get some subset of information about you from the api. The private key is for your use only, and provides access to all of your data.
It looks like that many people use API keys as a security solution. The bottom line is: Never treat API keys as secret it is not. On https or not, whoever can read the request can see the API key and can make whatever call they want. An API Key should be just as a 'user' identifier as its not a complete security solution even when used with ssl.
The better description is in Eugene Osovetsky link to: When working with most APIs, why do they require two types of authentication, namely a key and a secret?
Or check http://nordicapis.com/why-api-keys-are-not-enough/
An API key is a unique value that is assigned to a user of this service when he's accepted as a user of the service.
The service maintains all the issued keys and checks them at each request.
By looking at the supplied key at the request, a service checks whether it is a valid key to decide on whether to grant access to a user or not.
API keys are just one way of authenticating users of web services.
Think of it this way, the "Public API Key" is similar to a user name that your database is using as a login to a verification server. The "Private API Key" would then be similar to the password. By the site/databse using this method, the security is maintained on the third party/verification server in order to authentic request of posting or editing your site/database.
The API string is just the URL of the login for your site/database to contact the verification server.