Mixing
DDS Security certificate storage
up vote
1
down vote
favorite
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 2 days ago
Reinier Torenbeek
8,97722845
asked 2 days ago
Stoogy
454318
add a comment |
up vote
1
down vote
favorite
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 2 days ago
Reinier Torenbeek
8,97722845
asked 2 days ago
Stoogy
454318
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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 2 days ago
Reinier Torenbeek
8,97722845
asked 2 days ago
Stoogy
454318
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 2 days ago
Reinier Torenbeek
8,97722845
asked 2 days ago
Stoogy
454318
edited 2 days ago
Reinier Torenbeek
8,97722845
asked 2 days ago
Stoogy
454318
edited 2 days ago
Reinier Torenbeek
8,97722845
edited 2 days ago
Reinier Torenbeek
8,97722845
edited 2 days ago
Reinier Torenbeek
8,97722845
8,97722845
asked 2 days ago
Stoogy
454318
asked 2 days ago
Stoogy
454318
asked 2 days ago
Stoogy
454318
454318
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
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 2 days ago
Reinier Torenbeek
8,97722845
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...
21 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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 2 days ago
Reinier Torenbeek
8,97722845
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...
21 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
add a comment |
up vote
1
down vote
accepted
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 2 days ago
Reinier Torenbeek
8,97722845
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...
21 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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 2 days ago
Reinier Torenbeek
8,97722845
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 2 days ago
Reinier Torenbeek
8,97722845
answered 2 days ago
Reinier Torenbeek
8,97722845
answered 2 days ago
Reinier Torenbeek
8,97722845
answered 2 days ago
Reinier Torenbeek
8,97722845
8,97722845
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...
21 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
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...
21 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
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...
21 hours ago
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...
21 hours ago
@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
11 hours ago
@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
11 hours ago
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...
7 hours ago
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...
7 hours ago
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...
7 hours ago
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...
7 hours ago
add a comment |
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
