 |
 |
Micah, Thank you for a wonderfully thought out post. I have been trying to formulate some of the concerns you mention in 3 and you've done it with far more authority. I have another question which might be naive, but, in addition to loss of access to content because of loss of proprietary encryption technology/knowledge would it also not be a possible threat that the entire PKI infrastructure could change over a long enough period of time? That, for example, current mechanisms for obtaining keys and revocation lists etc. could become unused and unavailable? Priscilla (I have a conflict with this afternoon's call and I really hate to miss this discussion. Thanks Andrea for raising it.) On 2/28/2012 12:03 PM, Dr. Micah Altman wrote: > A few thoughts, in preparation for our call today... > > 1. Theoretically, maintenance of keys is straightforward although complex: > e.g. > (a) use a distributed PKI -- either (i) hierarchical or (ii) PGP-style > (b) maintain physically protected copies off-line > (c) escrow keys (possibly divided) with multiple (partially) trusted > third parties > > > 2. In practice, few organizations have good enterprise key management, and > its been unexpectedly difficult to maintain even over the course of normal > business timescales. Some commonly encountered challenges include: > - managing key revocation and possible re-encryption of content using a > revoked key > - enterprise scaling of key management (esp. a(ii) (b) and (c) ) > - enterprise scaling of performance over encrypted content (e.g. > barriers to deduplication of virtualized storage; overhead for computing on > encrypted content; performance issues with encrypted filesystems; barriers > to standard storage maintenance/recovery/integrity auditing ) > - enabling collaboration with encrypted content (managing appropriate > group access to content, while maintaining desired security properties) > - potential catastrophic single point security failures for PKI ( esp. > certificate issuing, checking, revocation architecture) > - proprietary encryption algorithms (esp. hardware embedded) > > 3. A key issue for preservation is managing risks to long term access, use > of encryption creates additional risks for catastrophic / correlated/ > single-point long-term access failure, such as: > - undetected corruption of content due to defects in encryption > hardware/software > - " " due to increased barriers to auditing > - increased risk of content corruption due to barriers to > filesystem maintenance/recovery of encrypted content > - loss of access to content because of loss of proprietary encryption > technology/knowledge (try reading a hardware encrypted tape from 10 years > ago :-( > - " " because of unintentional loss of key > - " " because of unintentional/incorrect revocation/key destruction (e.g. > "self destruct" mechanisms on encrypted hardware, such as IronKeys) > - Financial risks to access because of increased costs of maintaining > encryption > > > None of these are necessarily show stoppers -- in a particular environment > one could of possible ways to mitigate these risks, project costs, compare > to the benefits of encryption, and make a decision either way... Unless > security experts are involved, risks from misimplementation or defects in > the security software/hardware/protocols (etc.) are usually not on the > radar; and additional risks for long term access are generally not on the > radar even where a trained security expert is engaged. So its important to > make sure that we, as preservation experts, communicate these additional > long-term access risks and costs ... > > best, > > Micah > > However, a key point is that most decisions to use encryption are driven by > non-access-related business needs (such as HIPAA compliance) , and analyzed > by mid-level IT for risks occurring during the standard business > time-horizon. > > > > On Thu, Feb 23, 2012 at 4:51 PM, Cory Snavely<[log in to unmask]> wrote: > >> Sure. >> >> What I had said in my email was "Long-term secure preservation of the >> decryption keys themselves is typically raised as a concern, although >> personally I feel that solutions to this problem are straightforward, >> albeit complex." >> >> I view this as a compound problem that requires a combination of >> preservation storage principles and security principles to solve. >> >> First, the preservation storage part. There have to be multiple copies of >> the keys. Organizations doing digital preservation should be operating at >> multiple sites, and so it should be straightforward to take advantage of >> this to place copies at the multiple sites - the more the better. >> >> Second, the security part. The keys themselves obviously have to be >> secured in some way. This can be done with either additional encryption or >> physical security, ie a locking safe, or both. The key point is that this >> chain ultimately ends in human knowledge, i.e., people have to know >> secrets. The trick is ensuring that enough people know enough secrets to >> eventually lead to the encryption keys. Providing office staff at multiple >> sites with combinations to safes that contain the encrypted encryption keys >> that a more privileged group of repository administrators know the secret >> for is an example of adding multiple layers into the scheme. >> >> It is tempting, of course, to think of disaster scenarios where all >> secrets are lost. It's my assertion that this can in turn be addressed with >> multiple sites. >> >> It's impossible to reduce the risk of data loss due to lost keys to zero >> without undermining the encryption itself, but my point is that the risk >> can be brought into an acceptable range with a scheme that is >> well-thought-out by using technology and policy frameworks that we, as >> organizations doing digital preservation, ostensibly already possess. >> >> >> On 02/15/2012 10:01 PM, Andrew Woods wrote: >> >>> I am interested, Cory (and others), in your ideas around the issue of >>> long-term, secure management of the keys themselves. Would you be kind >>> enough to elaborate. >>> Andrew >>> >> ############################ >> >> To unsubscribe from the NDSA-INFRASTRUCTURE list: >> write to: mailto:NDSA-INFRASTRUCTURE-**[log in to unmask]** >> DIGITALPRESERVATION.GOV<[log in to unmask]> >> or click the following link: >> http://list.**digitalpreservation.gov/**SCRIPTS/WA-DIGITAL.EXE?SUBED1=** >> NDSA-INFRASTRUCTURE&A=1<http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1> >> > > ############################ To unsubscribe from the NDSA-INFRASTRUCTURE list: write to: mailto:[log in to unmask] or click the following link: http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1