Hi there.
I am trying to figure out how to use GemStone secure backups on GemStone 64Bit 3.4.1 on Linux. The documentation talks of private and public keys - things I understand and know how to generate using openssl. However, what confuses me is the contents of the directory $GEMSTONE/examples/openssl Specifically, there are scripts in there related to being a certificate authority, and there is a CA certificate. I see no mention of certificates and being a CA in documentation, so I wondered what it is used for and how? Regards Iwan -- _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Ah, I see that the certs are used by GsSecureSocket which makes sense. I
guess the secure backup examples just use the same directories for storing their keys as well. On 2019/09/04 12:13, Iwan Vosloo wrote: > Hi there. > > I am trying to figure out how to use GemStone secure backups on GemStone > 64Bit 3.4.1 on Linux. > > The documentation talks of private and public keys - things I understand > and know how to generate using openssl. > > However, what confuses me is the contents of the directory > $GEMSTONE/examples/openssl > > Specifically, there are scripts in there related to being a certificate > authority, and there is a CA certificate. > > I see no mention of certificates and being a CA in documentation, so I > wondered what it is used for and how? > > Regards > Iwan > > -- _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
On closer inspection though, I am still confused:
The docs talk about key pairs: > Secure backups require RSA keypairs, both for signing and for > encryption (if used); But, the method and the docs for the method talk about certificates: > publicKeyCerts: anArrayOrString > anArrayOfString - an array of names of public certificate files, or > nil if the backup will not be encrypted (if encryptionKind is 0). Up > to 8 may be included. At least one of the private keys corresponding > to these public keys will be needed in order to restore this backup Thats pertaining to encryption. For signing, I see: > signingKey: signingKeyFn > signingKeyPassphrase: aPassphrase > signingKeyFn - the name of the signing private key certificate file. > aPassphrase - the passphrase for the signing key certificate. So, for encryption, the docs in this instance refer to certificate files for both signing and encryption (even though the method names for signing seem to indicate a signingKey instead). Also, when I opened the relevant example files I saw they are indeed certificates. So the question then becomes: they're all certificates...but how does the CA and its private/public keys come into it? Does its public key need to be present when backing up or restoring using the certificates issued by it? Regards -Iwan On 2019/09/04 12:32, Iwan Vosloo via GemStone-Smalltalk wrote: > Ah, I see that the certs are used by GsSecureSocket which makes sense. I > guess the secure backup examples just use the same directories for > storing their keys as well. > > On 2019/09/04 12:13, Iwan Vosloo wrote: >> Hi there. >> >> I am trying to figure out how to use GemStone secure backups on >> GemStone 64Bit 3.4.1 on Linux. >> >> The documentation talks of private and public keys - things I >> understand and know how to generate using openssl. >> >> However, what confuses me is the contents of the directory >> $GEMSTONE/examples/openssl >> >> Specifically, there are scripts in there related to being a >> certificate authority, and there is a CA certificate. >> >> I see no mention of certificates and being a CA in documentation, so I >> wondered what it is used for and how? >> >> Regards >> Iwan >> >> > > -- _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
The certificates contain public keys, so the public keys come from
there. We do not validate the certificates, so there is no CA cert
file used here.
The signing key is a private key and can be RSA or DSA in the latest versions GemStone (initially it had to be RSA). It works like this:
To restore the backup, you need a private key that matches one of the certs used to create the backup. You also need the cert (public key) that matches the signing key to validate the backup has not been tampered with. Hope this helps.
Norm Green
On 9/3/2019 11:14 PM, Iwan Vosloo via
GemStone-Smalltalk wrote:
On closer inspection though, I am still confused: _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Thanks Norm,
that makes perfect sense and is the bit of explanation I was missing. Regards On 2019/09/04 16:53, Norm Green via GemStone-Smalltalk wrote: > The certificates contain public keys, so the public keys come from > there. We do not validate the certificates, so there is no CA cert file > used here. > > The signing key is a private key and can be RSA or DSA in the latest > versions GemStone (initially it had to be RSA). > > It works like this: > > 1. Generate a random encryption key (symmetric) > 2. For each certificate provided, use the cert to encrypt the > encryption key and store the encrypted form in the backup file. > 3. Write the backup file, encrypting each backup record using the > encryption key > 4. When finished, generate a hash of the backup and store it in the > backup file. > 5. Finally, use the signing key (RSA or DSA private key) to sign the > hash and store it in the backup file. > > To restore the backup, you need a private key that matches one of the > certs used to create the backup. You also need the cert (public key) > that matches the signing key to validate the backup has not been > tampered with. > > Hope this helps. > > > Norm Green > > > > On 9/3/2019 11:14 PM, Iwan Vosloo via GemStone-Smalltalk wrote: >> On closer inspection though, I am still confused: >> >> The docs talk about key pairs: >> >> > Secure backups require RSA keypairs, both for signing and for >> > encryption (if used); >> >> But, the method and the docs for the method talk about certificates: >> >> > publicKeyCerts: anArrayOrString >> >> > anArrayOfString - an array of names of public certificate files, or >> > nil if the backup will not be encrypted (if encryptionKind is 0). Up >> > to 8 may be included. At least one of the private keys corresponding >> > to these public keys will be needed in order to restore this backup >> >> Thats pertaining to encryption. For signing, I see: >> >> > signingKey: signingKeyFn >> > signingKeyPassphrase: aPassphrase >> >> > signingKeyFn - the name of the signing private key certificate file. >> > aPassphrase - the passphrase for the signing key certificate. >> >> So, for encryption, the docs in this instance refer to certificate >> files for both signing and encryption (even though the method names >> for signing seem to indicate a signingKey instead). >> >> Also, when I opened the relevant example files I saw they are indeed >> certificates. >> >> So the question then becomes: they're all certificates...but how does >> the CA and its private/public keys come into it? Does its public key >> need to be present when backing up or restoring using the certificates >> issued by it? >> >> >> Regards >> -Iwan >> >> >> On 2019/09/04 12:32, Iwan Vosloo via GemStone-Smalltalk wrote: >>> Ah, I see that the certs are used by GsSecureSocket which makes >>> sense. I guess the secure backup examples just use the same >>> directories for storing their keys as well. >>> >>> On 2019/09/04 12:13, Iwan Vosloo wrote: >>>> Hi there. >>>> >>>> I am trying to figure out how to use GemStone secure backups on >>>> GemStone 64Bit 3.4.1 on Linux. >>>> >>>> The documentation talks of private and public keys - things I >>>> understand and know how to generate using openssl. >>>> >>>> However, what confuses me is the contents of the directory >>>> $GEMSTONE/examples/openssl >>>> >>>> Specifically, there are scripts in there related to being a >>>> certificate authority, and there is a CA certificate. >>>> >>>> I see no mention of certificates and being a CA in documentation, so >>>> I wondered what it is used for and how? >>>> >>>> Regards >>>> Iwan >>>> >>>> >>> >>> >> >> > > > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk > -- _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
In reply to this post by Gemstone/S mailing list
I was wondering whether there is a way to rotate encryption certs that
were used in an old backup without having to go through a whole restore/backup again process? If not, can we make it a feature request? A quick version should be possible, if you: - use one of the encryption certs to get a decrypted version of the symmetric encryption key from the encrypted backup - delete all encrypted versions of the symmetric encryption key in place - create new encrypted versions of the symmetric key using a new set of encryption certs and update the backup file with them (Obviously the hash and signature will also have to be updated) A longer-running version might also rotate the symmetric encryption key as part of the process, but I'm not sure its necessary to go this far. Regards Iwan On 2019/09/04 16:53, Norm Green via GemStone-Smalltalk wrote: > The certificates contain public keys, so the public keys come from > there. We do not validate the certificates, so there is no CA cert file > used here. > > The signing key is a private key and can be RSA or DSA in the latest > versions GemStone (initially it had to be RSA). > > It works like this: > > 1. Generate a random encryption key (symmetric) > 2. For each certificate provided, use the cert to encrypt the > encryption key and store the encrypted form in the backup file. > 3. Write the backup file, encrypting each backup record using the > encryption key > 4. When finished, generate a hash of the backup and store it in the > backup file. > 5. Finally, use the signing key (RSA or DSA private key) to sign the > hash and store it in the backup file. > > To restore the backup, you need a private key that matches one of the > certs used to create the backup. You also need the cert (public key) > that matches the signing key to validate the backup has not been > tampered with. > > Hope this helps. > > > Norm Green > > > -- _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Hi Iwan,
On 9/8/2019 6:17 PM, Iwan Vosloo via GemStone-Smalltalk wrote: > I was wondering whether there is a way to rotate encryption certs that > were used in an old backup without having to go through a whole > restore/backup again process? Not currently. > > If not, can we make it a feature request? > Yes I can add a request. Could you please explain the practical use of such a feature? Also note that if the backup is comprised of multiple files, the certs in all backup files would need to be rotated, else the backup could not be restored. > A quick version should be possible, if you: > > - use one of the encryption certs to get a decrypted version of the > symmetric encryption key from the encrypted backup > - delete all encrypted versions of the symmetric encryption key in place > - create new encrypted versions of the symmetric key using a new set > of encryption certs and update the backup file with them > > (Obviously the hash and signature will also have to be updated) > > A longer-running version might also rotate the symmetric encryption > key as part of the process, but I'm not sure its necessary to go this > far. > > Regards > Iwan > > > On 2019/09/04 16:53, Norm Green via GemStone-Smalltalk wrote: >> The certificates contain public keys, so the public keys come from >> there. We do not validate the certificates, so there is no CA cert >> file used here. >> >> The signing key is a private key and can be RSA or DSA in the latest >> versions GemStone (initially it had to be RSA). >> >> It works like this: >> >> 1. Generate a random encryption key (symmetric) >> 2. For each certificate provided, use the cert to encrypt the >> encryption key and store the encrypted form in the backup file. >> 3. Write the backup file, encrypting each backup record using the >> encryption key >> 4. When finished, generate a hash of the backup and store it in the >> backup file. >> 5. Finally, use the signing key (RSA or DSA private key) to sign the >> hash and store it in the backup file. >> >> To restore the backup, you need a private key that matches one of the >> certs used to create the backup. You also need the cert (public key) >> that matches the signing key to validate the backup has not been >> tampered with. >> >> Hope this helps. >> >> >> Norm Green >> >> >> > > _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
If I may have some input on this conversation, I would suggest that rotating certs adds complexity, and complexity is the enemy of security. Without knowing all the details of specific security requirements, I think properly managing and securing a single certificate chain would be a better solution.
Jerry Kott This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
_______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Hi Norm,
>> On 08-09-2019, at 7:45 PM, Norm Green via GemStone-Smalltalk >> >> Yes I can add a request. Could you please explain the practical use >> of such a feature? I am just wondering how to handle the situation of a compromised key and similar situations where you want protect existing backups from access via a key that is no longer trusted. On 2019/09/09 13:11, Jerry Kott via GemStone-Smalltalk wrote: > If I may have some input on this conversation, I would suggest that > rotating certs adds complexity, and complexity is the enemy of security. > Without knowing all the details of specific security requirements, I > think properly managing and securing a single certificate chain would be > a better solution. I'd love to hear an elaboration. Regards Iwan _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Thanks for the info. I see your point about needing to switch keys of a
backup encrypted with a private key that has been compromised. I've submitted feature request 48314 to track the issue. I would imagine that copydbf could be enhanced so that a new backup file could be created with new pairs of encryption and signing keys. The caller would of course need to provide the old signing and encryption keys. Also the old file would not be modified in place. Norm On 9/8/2019 10:09 PM, Iwan Vosloo via GemStone-Smalltalk wrote: > Hi Norm, > > >> On 08-09-2019, at 7:45 PM, Norm Green via GemStone-Smalltalk > >> > >> Yes I can add a request. Could you please explain the practical use > >> of such a feature? > > > I am just wondering how to handle the situation of a compromised key > and similar situations where you want protect existing backups from > access via a key that is no longer trusted. > > > On 2019/09/09 13:11, Jerry Kott via GemStone-Smalltalk wrote: >> If I may have some input on this conversation, I would suggest that >> rotating certs adds complexity, and complexity is the enemy of >> security. Without knowing all the details of specific security >> requirements, I think properly managing and securing a single >> certificate chain would be a better solution. > > I'd love to hear an elaboration. > > Regards > Iwan > > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
On 2019/09/10 00:45, Norm Green via GemStone-Smalltalk wrote:
> Thanks for the info. I see your point about needing to switch keys of > a backup encrypted with a private key that has been compromised. > > I've submitted feature request 48314 to track the issue. Great, thank you Norm. Regards Iwan _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Free forum by Nabble | Edit this page |