The Zombie Stack Exchanges That Just Won't Die
Encrypting content could help ease fears about unauthorized access (sayto copyrighted materials or sensitive information) but it results in adependency on encryption keys. I would be curious to know what peoplesee as the pros and cons of encrypting content a stewardshiporganization is preserving. With the pros and cons in mind, when (ifever) do you think a responsible organization should be encrypting filesthey are preserving and when do you think they shouldn't?
Trevor Owens
- digital-preservation
Comments
Answer by Nick Krabbenhoeft
Pros:
- Restricted access
- Encryption protects confidential information and preventsunauthorized copying of commercial materials.
Cons:
Increased vulnerability to bit rot - Bit rot in an encrypted objectwould result in severe loss, since the object could only bedecrypted up to the bit loss or it would be completely illegible.This is mitigated by a good fixity check and backup system.
Maintaining the keys - Using keys to access contents introduces moredependencies for continued access to the object. This is mitigatedby a good fixity check and backup system and recording therelationship in metadata.
Encryptions getting cracked - AES is a very strong encryptionstandard; however, because it's a math problem, mathematicians areconstantly trying to create faster-than-brute-forcesolutions.Public-key encryption might be stronger against brute force attacks,but quantum computers would render it trivial. Once any encryptionis cracked, all restricted files would have to be re-encrypted.(Maybe with quantumencryption.)
Personally, encryption for restricted files is not appealing. Itincreases the repository's exposure to catastrophic losses and thedemands on the repository's internal and external monitoring processes.I would prefer to restrict access with locked-down terminals incontrolled locations, strong user authentication requirements for remoteaccess, or other solutions.
An intermediary solution might be the iTunes solution. Songs on itscentral server are encrypted, but the key is stored in the file. Whenyou buy a song, this key is encrypted with a random key unique to youraccount.
Only in cases where information must remain protected (e.g. NSA servers)does a repository of encrypted data warrant the preservation risks.
Comments
Answer by Cory Snavely
Pros:
A reiteration of the above, which I think is generally agreed upon:strong encryption reduces worries associated with unauthorizedaccess to preservation copies of materials (such as copyrighteddata). This may in turn enable relatively insecure (read: "cheap" or"cloud") infrastructure to be used for the preservation of highlysensitive materials.
Encryption doubles as an authenticity check, and in fact, someencryption methods involve the creation of a digital signature thatcan be used for provenance or bit rot detection.
Cons:
Encryption causes file size bloat to the tune of 20-30%.
For light archives, encryption imparts a performance penalty forsystems that need to extract the content from the preservationarchive for access purposes.
Another re-iteration: long-term secure preservation of theencryption keys themselves is typically raised as a legitimateconcern. Fundamentally this problem is the result of two conflictingrequirements: that the encryption keys be held by as few entities aspossible to maintain their security, but also that they be easilyacquired in disaster scenarios. I suggest that digital preservationrepositories can mitigate (yet not fully eliminate) this concern bydeveloping a management system for the encryption keys thatleverages the technology frameworks (such as that for maintainingmultiple copies with integrity checks) and policy frameworks (suchas robust succession plans) that they ostensibly should have inplace by virtue of being qualified digital preservationrepositories. One can imagine an architecture, for example, whereencryption keys are safely stored within the repository itself andencrypted using a Shamir's Secret Sharing scheme that would requirethe consensual participation of any seven of thirteen parties namedin the succession plan in order to obtain them.
Not-cons: :)
- Personally, I don't buy the blanket argument that encryptionincreases the risk of bit rot because the argument assumes that theunencrypted form of the object is in fact resilient to single-biterror. I suggest that this risk be evaluated on a case-by-casebasis, and depending on the architecture of the repository, mayrepresent no additional preservation risk. Moreover, I suspect thatmany if not most preservation repositories store content that isalready sensitive to single-bit error by virtue of compression orthe intrinsic nature of certain file formats.
As with almost every other design aspect of digital preservationrepositories, the use of encryption presents both utility and risk thatshould be carefully considered.
Comments
- Nick Krabbenhoeft: The chance of bit rot loss on a file level is probably similar betweenencrypted and unencrypted files. However, if you're packaging otherobjects with the original like metadata or access copies, all theobjects accumulate the risks of their neighbors. To avoid that, you'dhave to encrypt below the AIP level. A good system prevents bit rot, butI think it's better to plan for the contingency.
- Chris Adams: Note that while some encryption systems can increase file size, this isjust an artifact of those systems rather than an unavoidable rule. Runsomething like `openssl aes-256-cbc -in file -out encrypted_file` toconfirm.
- Chris Adams: Also: very strong +1 on rejecting the bit rot argument. bit rot needs tobe addressed separately and comprehensively, not by hoping that filescan be painfully recovered later.
Answer by Henk Koning
I recently have been doing some experimentation with encryption. I thinkat this moment that encryption is a useful and easy way to add one extralayer of protection, in the (rare) cases where this is felt necessaryabove the established level of security.
All security measures can lose their effectiveness over time, so allmeasures must be actively managed.
There is indeed a 'problem' of the management of the decryption keys.This problem should not be exaggerated. I have been looking for bestpractices for managing decryption keys, but up until now found no goodreference for this. Any references welcome!
I can offer these points for consideration: - the decryption keys shouldbe stored in way that is technically and logically sufficientlyseparated from the storage of the corresponding files, so that anintruder who achieves access to the encrypted files is not likely tohave access to the decryption keys. This is a very important point andshould be considered carefully and repeatedly (external securityaudit?). - the decryption keys should never be transported together withthe related encrypted files - storage of the decryption keys does not /should not have a higher level of security as the storage of theencrypted files. The reason for this is that the organization isprobably not familiar with higher levels of security, and higher levelsof security introduce risks (too few people informed; unfamiliartechnical solutions; no security audits because it is so little data) -don't use generic decryption keys which apply to a lot of files
Whether these suggestion really apply depends very much on the scenarioyou have in mind. At this moment I am thinking of a small number ofselected files in our archive which are encrypted.
A completely different scenario would be an extra copy of all the filesin our archive stored somewhere in the cloud, with all the files havingthe same decryption key. In this scenario it is not the problem of themanagement of decryption keys, but the management of this single onedecryption key. Probably known only within a small circle of technicalsupporters. A loss of the key is no problem, as long as it is discoveredsoon. In that case the level of added data security because of the extracopy of all the files is lowered until a new copy is produced. The samegoes for the account information and the passwords you need to accessthe extra copy. A seed based on the file name and path can help here. Ifyou don't trust the cloud environment all encrypting and decryptingshould take place in the original data environment.
