LISTSERV mailing list manager LISTSERV 16.5

Help for NDSA-INFRASTRUCTURE Archives


NDSA-INFRASTRUCTURE Archives

NDSA-INFRASTRUCTURE Archives


NDSA-INFRASTRUCTURE@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

NDSA-INFRASTRUCTURE Home

NDSA-INFRASTRUCTURE Home

NDSA-INFRASTRUCTURE  February 2012, Week 4

NDSA-INFRASTRUCTURE February 2012, Week 4

Subject:

Re: storage topic 1: encryption

From:

Priscilla Caplan <[log in to unmask]>

Reply-To:

The NDSA infrastructure working group list <[log in to unmask]>

Date:

Tue, 28 Feb 2012 12:23:09 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (147 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

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

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager