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