DDS Security certificate storage
I am currently developing using DDS with the security plugins enable.
When the application starts, it looks for the path to the CA certificate, Local certificate and private key and load them in memory for future usage.
Certificates containing the public keys are not sensitive as they are usually sent in clear and checked using the CA certificate. So an attacker has no need to get access to it. Is that correct?
However, on a Ubuntu filesystem, how can I protect the private key? The only way I see is to put the key as Read-Only only for a specific user that will run the application. But because of privilege escalation, this seems insecure.
Are there secure way to secure private keys on a filesystem ?
About the permissions_ca and Governance/Permissions documents, if those are updated by an attacker (which would create its own CA and sign new Governance/Permissions documents), then, can an application could have more permissions? Meaning that those documents should be secured on the filesystem?
dds data-distribution-service
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
add a comment |
I am currently developing using DDS with the security plugins enable.
When the application starts, it looks for the path to the CA certificate, Local certificate and private key and load them in memory for future usage.
Certificates containing the public keys are not sensitive as they are usually sent in clear and checked using the CA certificate. So an attacker has no need to get access to it. Is that correct?
However, on a Ubuntu filesystem, how can I protect the private key? The only way I see is to put the key as Read-Only only for a specific user that will run the application. But because of privilege escalation, this seems insecure.
Are there secure way to secure private keys on a filesystem ?
About the permissions_ca and Governance/Permissions documents, if those are updated by an attacker (which would create its own CA and sign new Governance/Permissions documents), then, can an application could have more permissions? Meaning that those documents should be secured on the filesystem?
dds data-distribution-service
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
add a comment |
I am currently developing using DDS with the security plugins enable.
When the application starts, it looks for the path to the CA certificate, Local certificate and private key and load them in memory for future usage.
Certificates containing the public keys are not sensitive as they are usually sent in clear and checked using the CA certificate. So an attacker has no need to get access to it. Is that correct?
However, on a Ubuntu filesystem, how can I protect the private key? The only way I see is to put the key as Read-Only only for a specific user that will run the application. But because of privilege escalation, this seems insecure.
Are there secure way to secure private keys on a filesystem ?
About the permissions_ca and Governance/Permissions documents, if those are updated by an attacker (which would create its own CA and sign new Governance/Permissions documents), then, can an application could have more permissions? Meaning that those documents should be secured on the filesystem?
dds data-distribution-service
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
I am currently developing using DDS with the security plugins enable.
When the application starts, it looks for the path to the CA certificate, Local certificate and private key and load them in memory for future usage.
Certificates containing the public keys are not sensitive as they are usually sent in clear and checked using the CA certificate. So an attacker has no need to get access to it. Is that correct?
However, on a Ubuntu filesystem, how can I protect the private key? The only way I see is to put the key as Read-Only only for a specific user that will run the application. But because of privilege escalation, this seems insecure.
Are there secure way to secure private keys on a filesystem ?
About the permissions_ca and Governance/Permissions documents, if those are updated by an attacker (which would create its own CA and sign new Governance/Permissions documents), then, can an application could have more permissions? Meaning that those documents should be secured on the filesystem?
dds data-distribution-service
dds data-distribution-service
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
edited Nov 19 at 23:40
Reinier Torenbeek
9,43722847
9,43722847
asked Nov 19 at 11:04
Stoogy
548522
asked Nov 19 at 11:04
Stoogy
548522
asked Nov 19 at 11:04
Stoogy
548522
548522
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Most of your questions are not specific to DDS Security, but are about general Public Key Infrastructure (PKI) mechanisms as leveraged by DDS Security.
Certificates containing the public keys are not sensitive as they are
usually sent in clear and checked using the CA certificate. So an
attacker has no need to get access to it. Is that correct?
Yes, that is correct. The built-in plugins as defined by the DDS Security specification use a PKI. The public key certificate does normally not contain any confidential information.
However, on a Ubuntu filesystem, how can I protect the private key?
Using "traditional" Unix permissions to allow only the owner of the file to access it is common practice. For example, SSH on Ubuntu by default stores private keys that way, in ~/.ssh. Additionally, the specification allows for encryption of the private key using a passphrase. That too is common practice.
Whether this is good enough for your scenario depends on your system's requirements. It is possible to integrate with existing, stronger key storage solutions like Windows certificate stores or macOS keychains by implementing customize security plugins. The pluggable architecture as defined in the spec was intended to allow for that, but the actual availability of such solutions depends on the DDS product that you are using.
About the permissions_ca and Governance/Permissions documents, if
those are updated by an attacker (which would create its own CA and
sign new Governance/Permissions documents), then, can an application
could have more permissions?
Both the Governance and Permissions documents have to be signed by a signing authority. Tampering with those files would break the signature verification and therefore would be detected by other Participants in the Domain.
All participants in the secured DDS Domain need to trust the same signing authority to make this mechanism work. For an attacker to successfully modify a Governance or Permissions document, it would have to have access to the private keys of the signing authority. Again, this is a common technique used in public key infrastructures similar to the public key certificate signing.
In spite of the tamper protection, it still makes sense to protect those files. The actual result of tampering or deletion of those files would be a denial of service, which is harmful as well.
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373257%2fdds-security-certificate-storage%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Most of your questions are not specific to DDS Security, but are about general Public Key Infrastructure (PKI) mechanisms as leveraged by DDS Security.
Certificates containing the public keys are not sensitive as they are
usually sent in clear and checked using the CA certificate. So an
attacker has no need to get access to it. Is that correct?
Yes, that is correct. The built-in plugins as defined by the DDS Security specification use a PKI. The public key certificate does normally not contain any confidential information.
However, on a Ubuntu filesystem, how can I protect the private key?
Using "traditional" Unix permissions to allow only the owner of the file to access it is common practice. For example, SSH on Ubuntu by default stores private keys that way, in ~/.ssh. Additionally, the specification allows for encryption of the private key using a passphrase. That too is common practice.
Whether this is good enough for your scenario depends on your system's requirements. It is possible to integrate with existing, stronger key storage solutions like Windows certificate stores or macOS keychains by implementing customize security plugins. The pluggable architecture as defined in the spec was intended to allow for that, but the actual availability of such solutions depends on the DDS product that you are using.
About the permissions_ca and Governance/Permissions documents, if
those are updated by an attacker (which would create its own CA and
sign new Governance/Permissions documents), then, can an application
could have more permissions?
Both the Governance and Permissions documents have to be signed by a signing authority. Tampering with those files would break the signature verification and therefore would be detected by other Participants in the Domain.
All participants in the secured DDS Domain need to trust the same signing authority to make this mechanism work. For an attacker to successfully modify a Governance or Permissions document, it would have to have access to the private keys of the signing authority. Again, this is a common technique used in public key infrastructures similar to the public key certificate signing.
In spite of the tamper protection, it still makes sense to protect those files. The actual result of tampering or deletion of those files would be a denial of service, which is harmful as well.
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
add a comment |
Most of your questions are not specific to DDS Security, but are about general Public Key Infrastructure (PKI) mechanisms as leveraged by DDS Security.
Certificates containing the public keys are not sensitive as they are
usually sent in clear and checked using the CA certificate. So an
attacker has no need to get access to it. Is that correct?
Yes, that is correct. The built-in plugins as defined by the DDS Security specification use a PKI. The public key certificate does normally not contain any confidential information.
However, on a Ubuntu filesystem, how can I protect the private key?
Using "traditional" Unix permissions to allow only the owner of the file to access it is common practice. For example, SSH on Ubuntu by default stores private keys that way, in ~/.ssh. Additionally, the specification allows for encryption of the private key using a passphrase. That too is common practice.
Whether this is good enough for your scenario depends on your system's requirements. It is possible to integrate with existing, stronger key storage solutions like Windows certificate stores or macOS keychains by implementing customize security plugins. The pluggable architecture as defined in the spec was intended to allow for that, but the actual availability of such solutions depends on the DDS product that you are using.
About the permissions_ca and Governance/Permissions documents, if
those are updated by an attacker (which would create its own CA and
sign new Governance/Permissions documents), then, can an application
could have more permissions?
Both the Governance and Permissions documents have to be signed by a signing authority. Tampering with those files would break the signature verification and therefore would be detected by other Participants in the Domain.
All participants in the secured DDS Domain need to trust the same signing authority to make this mechanism work. For an attacker to successfully modify a Governance or Permissions document, it would have to have access to the private keys of the signing authority. Again, this is a common technique used in public key infrastructures similar to the public key certificate signing.
In spite of the tamper protection, it still makes sense to protect those files. The actual result of tampering or deletion of those files would be a denial of service, which is harmful as well.
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
add a comment |
Most of your questions are not specific to DDS Security, but are about general Public Key Infrastructure (PKI) mechanisms as leveraged by DDS Security.
Certificates containing the public keys are not sensitive as they are
usually sent in clear and checked using the CA certificate. So an
attacker has no need to get access to it. Is that correct?
Yes, that is correct. The built-in plugins as defined by the DDS Security specification use a PKI. The public key certificate does normally not contain any confidential information.
However, on a Ubuntu filesystem, how can I protect the private key?
Using "traditional" Unix permissions to allow only the owner of the file to access it is common practice. For example, SSH on Ubuntu by default stores private keys that way, in ~/.ssh. Additionally, the specification allows for encryption of the private key using a passphrase. That too is common practice.
Whether this is good enough for your scenario depends on your system's requirements. It is possible to integrate with existing, stronger key storage solutions like Windows certificate stores or macOS keychains by implementing customize security plugins. The pluggable architecture as defined in the spec was intended to allow for that, but the actual availability of such solutions depends on the DDS product that you are using.
About the permissions_ca and Governance/Permissions documents, if
those are updated by an attacker (which would create its own CA and
sign new Governance/Permissions documents), then, can an application
could have more permissions?
Both the Governance and Permissions documents have to be signed by a signing authority. Tampering with those files would break the signature verification and therefore would be detected by other Participants in the Domain.
All participants in the secured DDS Domain need to trust the same signing authority to make this mechanism work. For an attacker to successfully modify a Governance or Permissions document, it would have to have access to the private keys of the signing authority. Again, this is a common technique used in public key infrastructures similar to the public key certificate signing.
In spite of the tamper protection, it still makes sense to protect those files. The actual result of tampering or deletion of those files would be a denial of service, which is harmful as well.
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
Most of your questions are not specific to DDS Security, but are about general Public Key Infrastructure (PKI) mechanisms as leveraged by DDS Security.
Certificates containing the public keys are not sensitive as they are
usually sent in clear and checked using the CA certificate. So an
attacker has no need to get access to it. Is that correct?
Yes, that is correct. The built-in plugins as defined by the DDS Security specification use a PKI. The public key certificate does normally not contain any confidential information.
However, on a Ubuntu filesystem, how can I protect the private key?
Using "traditional" Unix permissions to allow only the owner of the file to access it is common practice. For example, SSH on Ubuntu by default stores private keys that way, in ~/.ssh. Additionally, the specification allows for encryption of the private key using a passphrase. That too is common practice.
Whether this is good enough for your scenario depends on your system's requirements. It is possible to integrate with existing, stronger key storage solutions like Windows certificate stores or macOS keychains by implementing customize security plugins. The pluggable architecture as defined in the spec was intended to allow for that, but the actual availability of such solutions depends on the DDS product that you are using.
About the permissions_ca and Governance/Permissions documents, if
those are updated by an attacker (which would create its own CA and
sign new Governance/Permissions documents), then, can an application
could have more permissions?
Both the Governance and Permissions documents have to be signed by a signing authority. Tampering with those files would break the signature verification and therefore would be detected by other Participants in the Domain.
All participants in the secured DDS Domain need to trust the same signing authority to make this mechanism work. For an attacker to successfully modify a Governance or Permissions document, it would have to have access to the private keys of the signing authority. Again, this is a common technique used in public key infrastructures similar to the public key certificate signing.
In spite of the tamper protection, it still makes sense to protect those files. The actual result of tampering or deletion of those files would be a denial of service, which is harmful as well.
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
answered Nov 19 at 23:39
Reinier Torenbeek
9,43722847
9,43722847
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
add a comment |
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
wrt 'about the permissions_ca and G/P documents', the best-practice answer is to store the signing authority's keys in an HSM. If you aren't using an HSM for the PKI signing keys, then yes, a wily attacker could simply replace the entire CA sub-system with their own, and then replace the Gov/Perm. documents en masse with doctored and 'correctly' signed certificates. Various CA infrastructures (Windows AD CS, EJBCA, etc) support use of an HSM as storage for CA private keys, and the root CA and even subordinate CAs can benefit from this.
– rip...
Nov 21 at 4:36
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
@rip...: If the signing keys are leaked then the security of the system is compromised, as usual with PKIs. So yes, they need to be protected properly. However, those signing keys are not supposed or needed to be present in the deployed DDS system. Your "wily attacker" would have to look somewhere else to find them, which is not the piece of cake like you are insinuating here.
– Reinier Torenbeek
Nov 21 at 14:29
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
It's possible that you inferred that, yes. I don't know where the private keys are held, except that "they should be held in an HSM".
– rip...
Nov 21 at 18:01
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
DDS Secure prevents "creating their own CA" -- a 'common' group of Participants must each use certificates that are descendants of a 'common' root CA. I'd still prefer to find out that the 'common' CA's private key for a weapon system is held in an HSM. I'm thinking about s/wily/state-level actor/, who does have the resources and patience to social-engineer or hack elevated access, and simply look in ~/.ssh for the private key.
– rip...
Nov 21 at 18:10
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373257%2fdds-security-certificate-storage%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
