|
|
And I'm happy to do further research and/or lit reviews on any of our conversation topics if the group thinks these conversations warrant that depth of detail (or perhaps if we want to repackage them for external publication or dissemination).
-----Original Message-----
From: The NDSA infrastructure working group list [mailto:[log in to unmask]] On Behalf Of Dr. Micah Altman
Sent: Tuesday, February 28, 2012 3:13 PM
To: [log in to unmask]
Subject: Re: [NDSA-INFRASTRUCTURE] storage topic 1: encryption
Following up on the conversation, Jefferson pointed out that no one on the list had pointed to literature on this. While PKI isn't my area of research here are some relevant articles from a shallow dive:
"Strategies for Ensuring Data Accessibility When Cryptographic Keys Are Lost" : http://www.giac.org/paper/gsec/783/strategies-ensuring-data-accessibility-cryptographic-keys-lost/101698
The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption : http://www.schneier.com/paper-key-escrow.html
Crypto Backup and Key Escrow : http://dl.acm.org/citation.cfm?id=227241
A taxonomy for key escrow encryption systems :
http://faculty.nps.edu/dedennin/publications/Taxonomy-CACM.pdf
(And 150+ citing articles:
http://scholar.google.com/scholar?hl=en&lr=&cites=49628270739110236&um=1&ie=UTF-8&ei=zjRNT_K8BYuD0QGlzon3Ag&sa=X&oi=science_links&ct=sl-citedby&resnum=3&ved=0CD4QzgIwAg
)
Although weighted towards "key escrow" solutions they seem to have substantial relevance to long term access.
On Tue, Feb 28, 2012 at 12:23 PM, Priscilla Caplan <[log in to unmask]> wrote:
>
> 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]
>>> ITALPRESERVATION.GOV>
>>>
>>> or click the following link:
>>> http://list.**digitalpreservation.gov/**SCRIPTS/WA-DIGITAL.EXE?SUBED
>>> 1=**
>>> 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]
> V
> or click the following link:
> 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
############################
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
|
|
|
|
|
Archives |
September 2024 May 2024 March 2024 May 2023 March 2023 February 2023 September 2022 July 2022 June 2022 January 2022 December 2021 November 2021 October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020 April 2020 March 2020 February 2020 January 2020 December 2019 November 2019 September 2019 August 2019 July 2019 June 2019 May 2019 April 2019 March 2019 February 2019 January 2019 November 2018 October 2018 September 2018 August 2018 July 2018 June 2018 May 2018 April 2018 March 2018 February 2018 January 2018 December 2017 November 2017 October 2017 November 2016 September 2016 August 2016 July 2016 June 2016 May 2016 April 2016 March 2016 February 2016 January 2016 December 2015 November 2015 October 2015 September 2015 August 2015 July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015 November 2014 October 2014 August 2014 July 2014 June 2014 May 2014 April 2014 March 2014, Week 2 March 2014 February 2014, Week 4 February 2014, Week 3 February 2014, Week 2 February 2014, Week 1 January 2014, Week 5 January 2014, Week 4 January 2014, Week 1 December 2013, Week 2 November 2013, Week 4 November 2013, Week 2 October 2013, Week 5 October 2013, Week 3 October 2013, Week 1 September 2013, Week 3 August 2013, Week 5 August 2013, Week 4 August 2013, Week 1 July 2013, Week 5 June 2013, Week 4 June 2013, Week 3 June 2013, Week 2 May 2013, Week 3 April 2013, Week 5 April 2013, Week 4 April 2013, Week 3 March 2013, Week 4 March 2013, Week 3 March 2013, Week 2 March 2013, Week 1 February 2013, Week 4 February 2013, Week 3 February 2013, Week 2 February 2013, Week 1 January 2013, Week 5 January 2013, Week 4 January 2013, Week 3 January 2013, Week 2 December 2012, Week 2 November 2012, Week 4 November 2012, Week 3 November 2012, Week 2 November 2012, Week 1 October 2012, Week 5 October 2012, Week 3 October 2012, Week 2 October 2012, Week 1 September 2012, Week 4 September 2012, Week 3 August 2012, Week 5 August 2012, Week 4 August 2012, Week 3 August 2012, Week 2 August 2012, Week 1 July 2012, Week 5 July 2012, Week 2 June 2012, Week 4 June 2012, Week 3 May 2012, Week 5 May 2012, Week 3 May 2012, Week 2 May 2012, Week 1 April 2012, Week 5 April 2012, Week 4 April 2012, Week 3 April 2012, Week 2 March 2012, Week 5 March 2012, Week 4 March 2012, Week 2 March 2012, Week 1 February 2012, Week 4 February 2012, Week 3 February 2012, Week 2 February 2012, Week 1 January 2012, Week 5 January 2012, Week 4 January 2012, Week 3 January 2012, Week 1 December 2011, Week 3 December 2011, Week 2 December 2011, Week 1 November 2011, Week 4 November 2011, Week 3 November 2011, Week 2 November 2011, Week 1 October 2011, Week 3 September 2011, Week 4 September 2011, Week 3 September 2011, Week 1 August 2011, Week 5 August 2011, Week 4 August 2011, Week 3 August 2011, Week 1 July 2011, Week 5 July 2011, Week 4 July 2011, Week 1 June 2011, Week 3 June 2011, Week 2 June 2011, Week 1 May 2011, Week 4 May 2011, Week 2 May 2011, Week 1 April 2011, Week 3 April 2011, Week 2 April 2011, Week 1 March 2011, Week 5 March 2011, Week 4 March 2011, Week 3 March 2011, Week 2 February 2011, Week 4 February 2011, Week 3 February 2011, Week 2 February 2011, Week 1 January 2011, Week 4 January 2011, Week 3 January 2011, Week 1 December 2010, Week 3 December 2010, Week 2 October 2010, Week 2 September 2010, Week 3 September 2010, Week 2 September 2010, Week 1 August 2010, Week 5
|
|