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>
>



-- 
*
----------------------------------------------------------------------------------------------------------------------------------
*
Micah Altman, Ph.D. <http://micahaltman.com>           Twitter: @drmaltman

Director of Research; Head/Scientist, Program on Information Research --
MIT Libraries, Massachusetts Institute of Technology
Non-Resident Senior Fellow, Brookings Institution
"Entia non sunt multiplicanda sine necessitate" - Doctor Invincibilis
(Corollary, "Ad indicia spectate.")

############################

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