4 ms·

You missed dllthomas's point. The private key should never exist outside a dedicated secure location, the "key bastion" as you say. dllthoms's point was that it

You missed dllthomas's point. The private key should never exist outside a dedicated secure location, the "key bastion" as you say. dllthoms's point was that it doesn't matter if the public key is also present in the secure location. There is no reason the keys have to be stored separately. That is orthogonal to the actual requirement that the private key is private aka. secret. In fact, the public key is public meaning it is assumed that anyone has or could gain access to it. It is purposefully published. So keeping the public key separate is meaningless. Since it is assumed that everyone has access to the public key we must assume that anyone who gains access to the private key has access to both. Ergo there is no reason to not store them both in the secure location.

jmillikin 13y ago
> There is no reason the keys have to be stored > separately. That is orthogonal to the actual requirement > that the private key is private aka. secret. It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. > In fact, the public key is public meaning it is assumed > that anyone has or could gain access to it. It is > purposefully published. So keeping the private key > separate is meaningless. This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key.
- deleted 13y ago
  [deleted]
- icebraining 13y ago
  A public key is a file. It can be stored in more than one place. For example, you can generate both inside the key bastion, and then copy the public key to the public servers, while leaving a copy on the bastion.
  - jmillikin 13y ago
    But that's not what Linode did. Linode put the private key right next to the public key, where anyone who compromised their web frontend could get at it. If they had kept their private key where it belonged, we wouldn't be having this discussion because their security alert would have said "...and we have verified that no credit card data was accessed".
    - dllthomas 13y ago
      And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.
- raylu 13y ago
  How does storing the public key on the key bastion make it useless?
  - jmillikin 13y ago
    The public key is used by the webserver to encrypt credit card data. If it was stored in the key bastion, it wouldn't be available to the webserver.
    - dllthomas 13y ago
      Okay, say you have the following scenario: 1) super secure server which handles only the processing of credit cards, handed off to it through a carefully specified API 2) webserver which talks to that server Obviously, the webserver needs the public key. There's no reason to delete the public key from the private server, but not really any reason not to. Now, let's say that, under certain circumstances, system 1 itself needs to add encrypted records. Now you need the key there too. You could 1) generate a different key-pair and track which key touches which, but for records generated by system 1 you're generating a keypair that might as well be a symmetric key, which you've objected to; or 2) you could encrypt those records with a symmetric key, but now you've got additional code paths to audit and maintain; or 3 you could send off a request to an external server but that seems to add more complexity and vulnerability not less. Just using the existing public key to encrypt those records doesn't seem like a bad idea - it's a message to the server in the future from the server now, and messages to someone get encrypted with their public key. Now, you've got a system where you have the public and private key sitting on the same server (and being used on the same server), and if someone does manage to get into that secure server (never impossible) the description I initially complained about would be equally applicable to this setup as to the setup Linode had.
    - raylu 13y ago
      Generally, you will have many copies of the public key on many servers.
- jdbernard 13y ago
  I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved: 1. The public area - meaning anyone has access. 2. The application context (server, etc) -- should be a "secured" location, meaning few people or processes have legitimate access, and measures should be taken to prevent unauthorized access. The private key should never be present in location 1, public area. The public key is expected to be available here. However, the problem would not be that the keys are together, but that the private key is available here at all, paired with the public or not. To be clear: I am saying the private key should never be available in context 1. The typical assumption in most scenarios is that context 2 is secure, and by that I mean secure enough to house the private key. After all, the actions taken in context 2 usually require the private key. So it is reasonable to say that we consider this area secure enough to house private keys, and then take adequate measures to protect it. In this case, if the public key is also stored here it is irrelevant, as the public key is already available in context 1. If you have made the decision that context 2 is safe enough for the private key then there is no reason not to also store the public. However, we have seen that in a typical deployment scenario context 2, the application context, is often compromised. This leads us to create context 3: 3. Dedicated secure key storage. This often comes in the form of an HSM or similar device. See http://en.wikipedia.org/wiki/Hardware_security_module http://en.wikipedia.org/wiki/Hardware_security_module The purpose of having an HSM is that instead of doing the cryptographic work (which requires the private key in clear) in context 2 , you send a work request to the HSM saying, "Here is the data I need you to work on, here is the cryptographic operation I need performed, and here is the private key identifier representing the private key I want you to use," the HSM performs the crypto operation, and returns the result. Importantly, the private key is never known outside the HSM. Even in this situation, there is no reason not to also store the public key in the HSM. In fact, it is very common to store both the public and private key parts in the HSM so that you can use the same API in your code (the key id) to reference both. Many crypto APIs have limited or no support for cryptographic operations using a key supplied from the outside (outside the HSM). This is on purpose. So often you have to keep the public key in the HSM too if you want to use the HSM for the crypto. > It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. No. No. No. It is true that you must publish the public key for others to use it, but that does not mean you cannot also store it in the secure location. As I have explained above it is often required that it also be present in the secure location. > This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key. No. You are not understanding what you are reading. I am saying that anyone who has access to the private key also has access to the public key, so there is no reason not to store them together in the secure location. I'll say it again: If you have the private key, you might as well have the public key. You would never distribute the private key. Period. And just because you store the public key in the same secure location as the private key does not mean you have to give everyone access to that secure location. You could, I don't know, make a copy of the public key to distribute by itself.
- alinajaf 13y ago
  You do realize that if you have the private key then generating the public key is trivial? As in you can run a single command with OpenSSL that does it?
cma 13y ago
What he might not realize is that SSH can generate the public key from its "private key" file, so there is literally no good way to have a private key separate from a public key.

jmillikin 13y ago

> There is no reason the keys have to be stored > separately. That is orthogonal to the actual requirement > that the private key is private aka. secret. It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. > In fact, the public key is public meaning it is assumed > that anyone has or could gain access to it. It is > purposefully published. So keeping the private key > separate is meaningless. This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key.

deleted 13y ago
[deleted]
icebraining 13y ago
A public key is a file. It can be stored in more than one place. For example, you can generate both inside the key bastion, and then copy the public key to the public servers, while leaving a copy on the bastion.
- jmillikin 13y ago
  But that's not what Linode did. Linode put the private key right next to the public key, where anyone who compromised their web frontend could get at it. If they had kept their private key where it belonged, we wouldn't be having this discussion because their security alert would have said "...and we have verified that no credit card data was accessed".
  - dllthomas 13y ago
    And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.
raylu 13y ago
How does storing the public key on the key bastion make it useless?
- jmillikin 13y ago
  The public key is used by the webserver to encrypt credit card data. If it was stored in the key bastion, it wouldn't be available to the webserver.
  - dllthomas 13y ago
    Okay, say you have the following scenario: 1) super secure server which handles only the processing of credit cards, handed off to it through a carefully specified API 2) webserver which talks to that server Obviously, the webserver needs the public key. There's no reason to delete the public key from the private server, but not really any reason not to. Now, let's say that, under certain circumstances, system 1 itself needs to add encrypted records. Now you need the key there too. You could 1) generate a different key-pair and track which key touches which, but for records generated by system 1 you're generating a keypair that might as well be a symmetric key, which you've objected to; or 2) you could encrypt those records with a symmetric key, but now you've got additional code paths to audit and maintain; or 3 you could send off a request to an external server but that seems to add more complexity and vulnerability not less. Just using the existing public key to encrypt those records doesn't seem like a bad idea - it's a message to the server in the future from the server now, and messages to someone get encrypted with their public key. Now, you've got a system where you have the public and private key sitting on the same server (and being used on the same server), and if someone does manage to get into that secure server (never impossible) the description I initially complained about would be equally applicable to this setup as to the setup Linode had.
  - raylu 13y ago
    Generally, you will have many copies of the public key on many servers.
jdbernard 13y ago
I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved: 1. The public area - meaning anyone has access. 2. The application context (server, etc) -- should be a "secured" location, meaning few people or processes have legitimate access, and measures should be taken to prevent unauthorized access. The private key should never be present in location 1, public area. The public key is expected to be available here. However, the problem would not be that the keys are together, but that the private key is available here at all, paired with the public or not. To be clear: I am saying the private key should never be available in context 1. The typical assumption in most scenarios is that context 2 is secure, and by that I mean secure enough to house the private key. After all, the actions taken in context 2 usually require the private key. So it is reasonable to say that we consider this area secure enough to house private keys, and then take adequate measures to protect it. In this case, if the public key is also stored here it is irrelevant, as the public key is already available in context 1. If you have made the decision that context 2 is safe enough for the private key then there is no reason not to also store the public. However, we have seen that in a typical deployment scenario context 2, the application context, is often compromised. This leads us to create context 3: 3. Dedicated secure key storage. This often comes in the form of an HSM or similar device. See http://en.wikipedia.org/wiki/Hardware_security_module http://en.wikipedia.org/wiki/Hardware_security_module The purpose of having an HSM is that instead of doing the cryptographic work (which requires the private key in clear) in context 2 , you send a work request to the HSM saying, "Here is the data I need you to work on, here is the cryptographic operation I need performed, and here is the private key identifier representing the private key I want you to use," the HSM performs the crypto operation, and returns the result. Importantly, the private key is never known outside the HSM. Even in this situation, there is no reason not to also store the public key in the HSM. In fact, it is very common to store both the public and private key parts in the HSM so that you can use the same API in your code (the key id) to reference both. Many crypto APIs have limited or no support for cryptographic operations using a key supplied from the outside (outside the HSM). This is on purpose. So often you have to keep the public key in the HSM too if you want to use the HSM for the crypto. > It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. No. No. No. It is true that you must publish the public key for others to use it, but that does not mean you cannot also store it in the secure location. As I have explained above it is often required that it also be present in the secure location. > This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key. No. You are not understanding what you are reading. I am saying that anyone who has access to the private key also has access to the public key, so there is no reason not to store them together in the secure location. I'll say it again: If you have the private key, you might as well have the public key. You would never distribute the private key. Period. And just because you store the public key in the same secure location as the private key does not mean you have to give everyone access to that secure location. You could, I don't know, make a copy of the public key to distribute by itself.
alinajaf 13y ago
You do realize that if you have the private key then generating the public key is trivial? As in you can run a single command with OpenSSL that does it?

cma 13y ago

What he might not realize is that SSH can generate the public key from its "private key" file, so there is literally no good way to have a private key separate from a public key.