EldoS | Feel safer!

Software components for data protection, secure storage and transfer

S3 Storage Demo Fails

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#15253
Posted: 12/08/2010 01:23:45
by Vsevolod Ievgiienko (EldoS Corp.)

Hello.

Quote

1) I assume the session key is generated by the encryption handler "on demand" to encrypt a new file, but where it is stored afterward so I can use it later for decryption?

The session key is stored inside the encrypted file and you do not work directly with it. To decrypt the file later you need to know GenericEncryptionKey used for encryption.
Quote

2) The KeyEncryptionAlgorithm options seem to all be symmetric. Shouldn't they key be encrypted with an asymmetric algorithm?

Key encryption algorithm is asymmetric only in case of using certificate-based encryption.
Quote

a) Is each file encrypted with only one key (its unique session key) or is a session key reused for several files over some duration?

Each file is encrypted with unique session key.
Quote

b) Are you simply saying that the one unique session key can be encrypted by several different user keys, so that several users can each have a copy of the session key?

Yes, one unique session key can be encrypted with several different user keys and later it can be decrypted with each of these user keys.
#15254
Posted: 12/08/2010 01:44:12
by Ken Ivanov (EldoS Corp.)

Quote
Key encryption algorithm is asymmetric only in case of using certificate-based encryption.

To be fair, KeyEncryptionAlgorithm property should be ALWAYS (in both certificate-based and generic key-based encryption cases) assigned with a symmetric encryption algorithm identifier (a constant that starts with "SB_ALGORITHM_CNT_" prefix). In certificate-based case, the "main" session key is first encrypted with another session key, and that second session key is then encrypted directly with public key contained in the certificate. That is, KeyEncryptionAlgorithm specifies the algorithm to use when encrypting main session key with auxiliary one.

It is not possible to specify public key algorithm directly (via a property), as it depends on the type of the particular public key and is taken from the certificate.
#15255
Posted: 12/08/2010 08:34:49
by Eric Lenington (Standard support level)
Joined: 12/06/2010
Posts: 37

Thank you for the details. I consider myself to have a good general understanding of encryption overall, but I'm trying to learn the details of your implementation.

Quote
The session key is stored inside the encrypted file and you do not work directly with it. To decrypt the file later you need to know GenericEncryptionKey used for encryption.


Just to be clear, the session key is completely contained in the encrypted file, not in a header or some meta data, right? So I could take the encrypted file off S3, move it somewhere else, and still decrypt it using the original generic key?

Quote
Yes, one unique session key can be encrypted with several different user keys and later it can be decrypted with each of these user keys.


Please explain how this would be done.


Regarding certificate-based encryption:
1) Why are there two session keys?
2) I assume that as it relates to the SBB components, I can essentially treat certificate and generic encryption the same way (i.e. I either supply a certificate OR a generic key, and the process of creating, encrypting, and storing the session key(s) happens automatically?
#15256
Posted: 12/08/2010 09:06:07
by Vsevolod Ievgiienko (EldoS Corp.)

Quote

Please explain how this would be done.

Using ElDefaultDataStorageSecurityHandler.GenericEncryptionKeys property you can make a list of user keys.
Quote

I assume that as it relates to the SBB components, I can essentially treat certificate and generic encryption the same way (i.e. I either supply a certificate OR a generic key, and the process of creating, encrypting, and storing the session key(s) happens automatically?

Yes this process is done automatically I you should not care about it.
#15257
Posted: 12/08/2010 14:20:41
by Eric Lenington (Standard support level)
Joined: 12/06/2010
Posts: 37

Quote
The session key is stored inside the encrypted file and you do not work directly with it. To decrypt the file later you need to know GenericEncryptionKey used for encryption.


Is the format of the encrypted file (header?, session key, encrypted data) something that is unique to SBB or do you use some documented standard?
#15258
Posted: 12/08/2010 16:55:59
by Ken Ivanov (EldoS Corp.)

Quote
Just to be clear, the session key is completely contained in the encrypted file, not in a header or some meta data, right? So I could take the encrypted file off S3, move it somewhere else, and still decrypt it using the original generic key?

We apologise for misleading you in the previous post. Encrypted session keys are contained in metadata associated with the protected object. Cloud components were designed to provide transparent data protection services (encrypt the data on-the-fly on upload and decrypt them on download). If you need to manage encryption/decryption yourself apart from sending and receiving objects from S3, you are free to use PKIBlackbox components (TElMessageEncryptor and TElMessageDecryptor) to perform encryption, and TElAWSS3DataStorage in pass-through mode to deal with S3 storage.

Quote
1) Why are there two session keys?

The first session key is used to encrypt the data itself. The second session key is used to encrypt the first session key. The second session key is generated basing on the key supplied by the user via GenericEncryptionKey(s) property. Two session keys are needed to allow data encryption by multiple users (just like this happens with certificate-based encryption).

Quote
2) I assume that as it relates to the SBB components, I can essentially treat certificate and generic encryption the same way (i.e. I either supply a certificate OR a generic key, and the process of creating, encrypting, and storing the session key(s) happens automatically?

Exactly. Just as an option, you can supply *both* certificate(s) and generic key(s) to have the object encrypted with all of them (so that it could be later decrypted with any of them).

Quote
Is the format of the encrypted file (header?, session key, encrypted data) something that is unique to SBB or do you use some documented standard?

As a quick answer, yes, the objects are stored in custom SBB-specific format.

The exact format of the stored object depends on the protection type being used. In the simplest case (no authentication information), the object kept in S3 is a CTR mode encrypted copy of the original file. All the encryption-related information is stored in the metadata associated with the object (the format of metadata is custom as well). We can provide you the details of all the custom formats used on request.

As far as I understand from your questions, you need the ability to manage encryption of files yourself (for instance, to be able to collect files from S3 and decrypt them later). If this is the case, I suggest you to have a look at PKI components for doing encryption, and to only use S3 components for uploading and downloading objects to/from S3.
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 3301 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!