Re: [cryptography] Techniques for protecting CA Root certificate Secret Key

2014-01-08 Thread ianG

On 9/01/14 02:49 AM, Paul F Fraser wrote:

Software and physical safe keeping of Root CA secret key are central to
security of a large set of issued certificates.
Are there any safe techniques for handling this problem taking into
account the need to not have the control in the hands of one person?
Any links or suggestions of how to handle this problem?



The easiest place to understand the formal approach would be to look at 
Baseline Requirements, which Joe pointed to.  It's the latest in a 
series of documents that has emphasised a certain direction.


However, it is not the only answer.  The best way to describe it is that 
it is 'best practices' for the CA industry, and once you achieve that 
way, you're on the path to being inculcated.  If that's your goal, the 
BR is your answer.


As you don't say much about your problem space is, it's difficult to 
answer your real question:  what are safe techniques for handling root 
CA keys?


(fwiw, the techniques described in BR are not safe, IMHO.  But they are 
industry 'best practice' so you might have to choose between loving 
acceptance and safety.)




iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Techniques for protecting CA Root certificate Secret Key

2014-01-08 Thread Joe St Sauver
Paul Fraser asked:

#Software and physical safe keeping of Root CA secret key are central to
#security of a large set of issued certificates. 
#
#Are there any safe techniques for handling this problem taking into account the
#need to not have the control in the hands of one person? 
#
#Any links or suggestions of how to handle this problem?

See Section 16.6 of the Certificate and Browser Forum Baseline Requirements
at https://www.cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf

For devices certified for FIPS 140 at level 3, check out
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm and
then search that web page for the appropriate level

For Common Criteria EAL 4 or higher, start with 
http://www.commoncriteriaportal.org/products/

Regards,

Joe
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


[cryptography] Omidyar-Greenwald Scam to Sell Crypto?

2014-01-08 Thread John Young



Pierre Omidyar's Business Model for First Look is Like a Second Life 
or Anti-Virus Guard Scam


http://3dblogger.typepad.com/wired_state/2014/01/pierre-omidyars-business-model-for-first-look-is-like-a-second-life-or-anti-virus-guard-scam.html

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Techniques for protecting CA Root certificate Secret Key

2014-01-08 Thread Natanael
Den 9 jan 2014 00:56 skrev "Paul F Fraser" :
>
> Software and physical safe keeping of Root CA secret key are central to
security of a large set of issued certificates.
> Are there any safe techniques for handling this problem taking into
account the need to not have the control in the hands of one person?
> Any links or suggestions of how to handle this problem?
>
> regards
>
> Paul Fraser

Hardware Security Modules are common. Kind of like smartcards (the chip on
your bank card), but big and fast, and usually supporting far more
protocols. Designed to be very hard to hack or otherwise extract the keys
from.

On the algorithmical level, there is Secure Multiparty Computation plus
Shamir's Secure Sharing Scheme, such that you need a group of chosen period
to work together to use the key to decrypt and sign things, while not
revealing the private key to anybody. The people who developed the Speedz
(spelling?) protocol is marketing a service for this.

- Sent from my phone
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


[cryptography] Techniques for protecting CA Root certificate Secret Key

2014-01-08 Thread Paul F Fraser
Software and physical safe keeping of Root CA secret key are central to security of a large set of 
issued certificates.
Are there any safe techniques for handling this problem taking into account the need to not have the 
control in the hands of one person?

Any links or suggestions of how to handle this problem?

regards

Paul Fraser

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] To Protect and Infect Slides

2014-01-08 Thread John Young

Thanks. We posted the Wassenaar changes on Cryptome
on December 19.

http://cryptome.org/2013/12/wassenaar-intrusion.htm

http://cryptome.org/2013/12/wassenaar-list-13-1204.pdf

The intrusion software has received some but not sufficient
attention. And beyond the sections you cite there are many
covering other technologies which interrelate and affect crypto.
Those have received even less attention, at least in crypto
world as far as we have seen.

The means to transceive crypto continue to be its Achilles
heel and appear headed toward crippling the whole body -- the
bubble in which crypto exists precariously dependent on
sophisticated support systems which, as seen in the Snowden
minimal releases, have overwhelmed public crypto security, not
least by leaving the impression public crypto was highly effective.

More attention to the support system presumably will be given
as the Snowden releases recommence, now dead stopped.
Greenwald claimed recently  that cryptographers and other
techies are now reviewing the material, much of which is
beyond the capabilities of journalists, lawyers and politicians.

The stumbling block of comprehensive Snowden disclosures
is that to do so, allegedly, could severely damage national security.
Uh oh, that terrible aroma of complicity to protect secrets
too dangerous for the public to know. Instead a few select experts
are allowed to perfomr dual-hat assessments. Which is what has led
to the current imbroglio of public and expert distrust: who watches
the dual-hat experts who operate under the cloak of secrecy.


At 04:38 PM 1/8/2014, you wrote:


Keying off of one phrase alone,

 > This combat is about far more than crypto...

I suggest you immediately familiarize yourself with last month's
changes to the Wassenaar Agreement, perhaps starting here:

http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance

Precis: Two new classes of export prohibited software:

Intrusion software

"Software" specially designed or modified to avoid detection
by 'monitoring tools', or to defeat 'protective countermeasures',
of a computer or network capable device, and performing any of
the following:

a. The extraction of data or information, from a computer or
network capable device, or the modification of system or user
data; or

b. The modification of the standard execution path of a program
or process in order to allow the execution of externally provided
instructions.

IP network surveillance systems

5. A. 1. j. IP network communications surveillance systems or
equipment, and specially designed components therefor, having
all of the following:

1. Performing all of the following on a carrier class IP network
(e.g., national grade IP backbone):

a. Analysis at the application layer (e.g., Layer 7 of Open
Systems Interconnection (OSI) model (ISO/IEC 7498-1));

b. Extraction of selected metadata and application content
(e.g., voice, video, messages, attachments); and

c. Indexing of extracted data; and

2. Being specially designed to carry out all of the following:

a. Execution of searches on the basis of 'hard selectors'; and

b. Mapping of the relational network of an individual or of a
group of people.


All the same arguments that applied exportation bans for crypto
software apply here, especially that of pointlessness.

--dan

[ Software doesn't spy on people; people spy on people ]



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] To Protect and Infect Slides

2014-01-08 Thread Paul Grubbs
New to the mailing list, sorry if this is formatted improperly.

Does the 'intrusion software' category include open-source stuff like
Metasploit?

Also, how will this affect software security testing by private companies?
Many infosec consulting companies have in-house proprietary software for
pentesting.


On Wed, Jan 8, 2014 at 1:38 PM,  wrote:

>
> Keying off of one phrase alone,
>
>  > This combat is about far more than crypto...
>
> I suggest you immediately familiarize yourself with last month's
> changes to the Wassenaar Agreement, perhaps starting here:
>
>
> http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance
>
> Precis: Two new classes of export prohibited software:
>
> Intrusion software
>
> "Software" specially designed or modified to avoid detection
> by 'monitoring tools', or to defeat 'protective countermeasures',
> of a computer or network capable device, and performing any of
> the following:
>
> a. The extraction of data or information, from a computer or
> network capable device, or the modification of system or user
> data; or
>
> b. The modification of the standard execution path of a program
> or process in order to allow the execution of externally provided
> instructions.
>
> IP network surveillance systems
>
> 5. A. 1. j. IP network communications surveillance systems or
> equipment, and specially designed components therefor, having
> all of the following:
>
> 1. Performing all of the following on a carrier class IP network
> (e.g., national grade IP backbone):
>
> a. Analysis at the application layer (e.g., Layer 7 of Open
> Systems Interconnection (OSI) model (ISO/IEC 7498-1));
>
> b. Extraction of selected metadata and application content
> (e.g., voice, video, messages, attachments); and
>
> c. Indexing of extracted data; and
>
> 2. Being specially designed to carry out all of the following:
>
> a. Execution of searches on the basis of 'hard selectors'; and
>
> b. Mapping of the relational network of an individual or of a
> group of people.
>
>
> All the same arguments that applied exportation bans for crypto
> software apply here, especially that of pointlessness.
>
> --dan
>
> [ Software doesn't spy on people; people spy on people ]
>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] To Protect and Infect Slides

2014-01-08 Thread dan

Keying off of one phrase alone,

 > This combat is about far more than crypto...

I suggest you immediately familiarize yourself with last month's
changes to the Wassenaar Agreement, perhaps starting here:

http://oti.newamerica.net/blogposts/2013/international_agreement_reached_controlling_export_of_mass_and_intrusive_surveillance

Precis: Two new classes of export prohibited software:

Intrusion software

"Software" specially designed or modified to avoid detection
by 'monitoring tools', or to defeat 'protective countermeasures',
of a computer or network capable device, and performing any of
the following:

a. The extraction of data or information, from a computer or
network capable device, or the modification of system or user
data; or

b. The modification of the standard execution path of a program
or process in order to allow the execution of externally provided
instructions.

IP network surveillance systems

5. A. 1. j. IP network communications surveillance systems or
equipment, and specially designed components therefor, having
all of the following:

1. Performing all of the following on a carrier class IP network
(e.g., national grade IP backbone):

a. Analysis at the application layer (e.g., Layer 7 of Open
Systems Interconnection (OSI) model (ISO/IEC 7498-1));

b. Extraction of selected metadata and application content
(e.g., voice, video, messages, attachments); and

c. Indexing of extracted data; and

2. Being specially designed to carry out all of the following:

a. Execution of searches on the basis of 'hard selectors'; and

b. Mapping of the relational network of an individual or of a
group of people.


All the same arguments that applied exportation bans for crypto
software apply here, especially that of pointlessness.

--dan

[ Software doesn't spy on people; people spy on people ]

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography