Re: ICSF master keys at DR site

2013-05-16 Thread R.S.

W dniu 2013-05-15 17:55, Frank Swarbrick pisze:

MK Ceremony.  I like that.  :-) Definitely what we'll have to do,
as I'm pretty sure we're not going to remove one of our cryptocards
and transport it to DR just for this.  Interesting idea, though!  Is
there a way to copy the master keys from one co-processor to
another?


IMHO You cannot copy master key, because you cannot read it. Of course 
you can enter MK to many cards at the time.


BTW: MK Ceremony is more ceremony or black magice than real security 
need. Imagine following scenario: simple PC with fresh-installed system 
+ 3270 emulator connected even without SSL to the OSA card, using 5 ft 
cable - all visible to the personnel involved. Now you can have several 
persons responsible for key parts and one standing behind the display to 
audit/manage the process. Don't forget about video surveillance - 
cameras cannot see the display. As last part of the ceremony is to wipe 
out the PC HDD (or destroy it if you want). Q: isn't it less secure than 
using TKE? In what aspect?


Disclaimers:
1. I'm NOT talking about official certifications, regulations, but about 
real things.

2. TKE can be used for other activities, not only MK Ceremony.
3. Preparation of the above scenario could be considered cumbersome, but 
pay me half of the TKE price, I will do it for you! ;-) Last, but not 
least: MK Ceremony is not everyday processs.



Regards
--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-16 Thread Rob Schramm
Todd... ooops.  That's what I get for relying on memory!!





Rob Schramm
Senior Systems Consultant
Imperium Group



On Wed, May 15, 2013 at 8:08 AM, Todd Arnold arno...@us.ibm.com wrote:

  There is/was a way to set a CEX card to allow it to keep the MK loaded
  while being transferred between machines.

 Yes, but you also need a TKE to do this.  You can enable or disable
 the crypto card.  When the card is disabled, you cannot perform any
 application-oriented crypto functions with it - for example, encrypting
 data, managing keys, etc.  The only things you can do are the functions
 related to re-enabling the card, which is done via TKE.  While the card is
 in disabled state, you can remove it from your machine and it will not
 lose any of the stored data such as the master keys - but you also cannot
 USE those master keys for anything until the card is re-enabled, and that
 is not possible except through TKE by two authorized administrators.

 Here is part of the description that is in the TKE user's manual:

 --
 A crypto module is either enabled or disabled. When a crypto module is
 enabled, it is available for processing. You can change the status of the
 module
 by pressing the Enable Crypto Module / Disable Crypto Module push button.
 Enable Crypto Module is a dual-signature command and another authority may
 need to co-sign. Disable Crypto Module is a single signature command.

 Disabling a crypto module disables all the cryptographic functions for a
 single
 crypto module, a group of crypto modules, or a domain group. This disables
 the
 crypto module for the entire system, not just the LPAR that issued the
 disable.
 --

 Todd Arnold

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-16 Thread Rob Schramm
Unless they own the DR machine... in which case it should become part of
the MK ceremony.

If you have 1 TKE and you own the DR machine, the TKE could manage the
remote site as well.  You would just have to setup the procedure to enroll
another TKE in the case of DR... and store a copy of the smart cards at the
2nd site.

The other way for MKs would be using tamper evident envelopes,
dual-controlled / logged access to the 3 key parts and some security
measure guarding the keys.  You should need at least 3 people to make a MK
ceremony... in reality.. it would probably be more.

Also, CLEARLY documented procedures that are easy to follow and have sign
off's for each of the steps.  Security logging/alerts, review of
logging/alerts that is verifiable.. escalation procedures for possible
breach, key change procedures... etc.

TKE should be setup in such a way as to prevent others from tampering..
dual locked cabinet?

Rob

Rob Schramm
Senior Systems Consultant
Imperium Group



On Thu, May 16, 2013 at 2:16 PM, Rob Schramm rob.schr...@gmail.com wrote:

 Todd... ooops.  That's what I get for relying on memory!!





 Rob Schramm
 Senior Systems Consultant
 Imperium Group



 On Wed, May 15, 2013 at 8:08 AM, Todd Arnold arno...@us.ibm.com wrote:

  There is/was a way to set a CEX card to allow it to keep the MK loaded
  while being transferred between machines.

 Yes, but you also need a TKE to do this.  You can enable or disable
 the crypto card.  When the card is disabled, you cannot perform any
 application-oriented crypto functions with it - for example, encrypting
 data, managing keys, etc.  The only things you can do are the functions
 related to re-enabling the card, which is done via TKE.  While the card is
 in disabled state, you can remove it from your machine and it will not
 lose any of the stored data such as the master keys - but you also cannot
 USE those master keys for anything until the card is re-enabled, and that
 is not possible except through TKE by two authorized administrators.

 Here is part of the description that is in the TKE user's manual:

 --
 A crypto module is either enabled or disabled. When a crypto module is
 enabled, it is available for processing. You can change the status of the
 module
 by pressing the Enable Crypto Module / Disable Crypto Module push button.
 Enable Crypto Module is a dual-signature command and another authority may
 need to co-sign. Disable Crypto Module is a single signature command.

 Disabling a crypto module disables all the cryptographic functions for a
 single
 crypto module, a group of crypto modules, or a domain group. This
 disables the
 crypto module for the entire system, not just the LPAR that issued the
 disable.
 --

 Todd Arnold

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-16 Thread Frank Swarbrick
We own the DR hardware, so hopefully that will not be necessary!  :-)
Thanks,
Frank






 From: Richard Peurifoy r-peuri...@neo.tamu.edu
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, May 16, 2013 9:49 AM
Subject: Re: ICSF master keys at DR site
 

On 5/15/2013 10:55 AM, Frank Swarbrick wrote:
 MK Ceremony.  I like that.  :-)
 Definitely what we'll have to do, as I'm pretty sure we're not going to 
 remove one of our cryptocards and transport it to DR just for this.  
 Interesting idea, though!  Is there a way to copy the master keys from one 
 co-processor to another?

Don't forget to clear your Master Key from the DR crypto card when
you leave.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-15 Thread Todd Arnold
 There is/was a way to set a CEX card to allow it to keep the MK loaded
 while being transferred between machines. 

Yes, but you also need a TKE to do this.  You can enable or disable the 
crypto card.  When the card is disabled, you cannot perform any 
application-oriented crypto functions with it - for example, encrypting data, 
managing keys, etc.  The only things you can do are the functions related to 
re-enabling the card, which is done via TKE.  While the card is in disabled 
state, you can remove it from your machine and it will not lose any of the 
stored data such as the master keys - but you also cannot USE those master keys 
for anything until the card is re-enabled, and that is not possible except 
through TKE by two authorized administrators.

Here is part of the description that is in the TKE user's manual:

--
A crypto module is either enabled or disabled. When a crypto module is
enabled, it is available for processing. You can change the status of the module
by pressing the Enable Crypto Module / Disable Crypto Module push button.
Enable Crypto Module is a dual-signature command and another authority may
need to co-sign. Disable Crypto Module is a single signature command.

Disabling a crypto module disables all the cryptographic functions for a single
crypto module, a group of crypto modules, or a domain group. This disables the
crypto module for the entire system, not just the LPAR that issued the disable.
--

Todd Arnold

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-15 Thread Frank Swarbrick
MK Ceremony.  I like that.  :-)
Definitely what we'll have to do, as I'm pretty sure we're not going to remove 
one of our cryptocards and transport it to DR just for this.  Interesting idea, 
though!  Is there a way to copy the master keys from one co-processor to 
another?






 From: Rob Schramm rob.schr...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 14, 2013 11:00 PM
Subject: Re: ICSF master keys at DR site
 

Actually... There is a method.  But it would be a bit silly... And might
fail for logistic reasons.

There is/was a way to set a CEX card to allow it to keep the MK loaded
while being transferred between machines.  I just remember reading about
it... Not all the details about how long the card could be removed before
re-installing it.

You can always do it the old fashion way. And have the MK parts stored at
the DR site and do a MK ceremony there not near as slick as having a
TKE.

Of course if you have a TKE at the primary site and store the MK on smart
cards .. you'll have to be a bit more creative.  But all the methods I can
think of leave you in a somewhat less secure state... Possibly managable...
But it would depend on the laws/regulation that you are under.

Rob Schramm
On May 14, 2013 1:11 PM, Frank Swarbrick frank.swarbr...@yahoo.com
wrote:

 Thank you (and Radoslaw) for your answers.




 
  From: Todd Arnold arno...@us.ibm.com
 To: IBM-MAIN@LISTSERV.UA.EDU
 Sent: Tuesday, May 14, 2013 7:35 AM
 Subject: Re: ICSF master keys at DR site
 
 
 Without a TKE, I don't think there is any other method.
 
 If you do have a TKE, there is a very nice and very secure method of
 completely cloning everything from one crypto card to another one.  This
 was added a couple of releases ago.  Here is the beginning of the
 description from the current TKE user's guide (which I just retrieved from
 Resource Link):
 
 ---
 Configuration migration
 
 The TKE workstation provides tools to securely capture host crypto module
 configuration data to a file, and then reapply this data to another host
 crypto
 module or crypto module group. The data that can be securely captured
 includes
 roles, authorities, domain control settings, and master keys. These tools
 simplify
 the task of installing new or replacement host crypto modules, and can be
 used for
 backup and disaster recovery as well.
 
 Two tools are provided: one that migrates only public configuration data
 (roles,
 authorities, domain control settings) and one that migrates all
 configuration data,
 including secret data, such as master key values. The protocol for
 migrating secret
 data is more complex than the protocol for migrating only public data, and
 requires the participation of several smart card holders.
 ---
 
 Todd Arnold
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-14 Thread Todd Arnold
Without a TKE, I don't think there is any other method.

If you do have a TKE, there is a very nice and very secure method of completely 
cloning everything from one crypto card to another one.  This was added a 
couple of releases ago.  Here is the beginning of the description from the 
current TKE user's guide (which I just retrieved from Resource Link):

---
Configuration migration

The TKE workstation provides tools to securely capture host crypto module
configuration data to a file, and then reapply this data to another host crypto
module or crypto module group. The data that can be securely captured includes
roles, authorities, domain control settings, and master keys. These tools 
simplify
the task of installing new or replacement host crypto modules, and can be used 
for
backup and disaster recovery as well.

Two tools are provided: one that migrates only public configuration data (roles,
authorities, domain control settings) and one that migrates all configuration 
data,
including secret data, such as master key values. The protocol for migrating 
secret
data is more complex than the protocol for migrating only public data, and
requires the participation of several smart card holders.
---

Todd Arnold

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-14 Thread Frank Swarbrick
Thank you (and Radoslaw) for your answers.





 From: Todd Arnold arno...@us.ibm.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 14, 2013 7:35 AM
Subject: Re: ICSF master keys at DR site
 

Without a TKE, I don't think there is any other method.

If you do have a TKE, there is a very nice and very secure method of 
completely cloning everything from one crypto card to another one.  This was 
added a couple of releases ago.  Here is the beginning of the description from 
the current TKE user's guide (which I just retrieved from Resource Link):

---
Configuration migration

The TKE workstation provides tools to securely capture host crypto module
configuration data to a file, and then reapply this data to another host crypto
module or crypto module group. The data that can be securely captured includes
roles, authorities, domain control settings, and master keys. These tools 
simplify
the task of installing new or replacement host crypto modules, and can be used 
for
backup and disaster recovery as well.

Two tools are provided: one that migrates only public configuration data 
(roles,
authorities, domain control settings) and one that migrates all configuration 
data,
including secret data, such as master key values. The protocol for migrating 
secret
data is more complex than the protocol for migrating only public data, and
requires the participation of several smart card holders.
---

Todd Arnold

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-14 Thread Rob Schramm
Actually... There is a method.  But it would be a bit silly... And might
fail for logistic reasons.

There is/was a way to set a CEX card to allow it to keep the MK loaded
while being transferred between machines.  I just remember reading about
it... Not all the details about how long the card could be removed before
re-installing it.

You can always do it the old fashion way. And have the MK parts stored at
the DR site and do a MK ceremony there not near as slick as having a
TKE.

Of course if you have a TKE at the primary site and store the MK on smart
cards .. you'll have to be a bit more creative.  But all the methods I can
think of leave you in a somewhat less secure state... Possibly managable...
But it would depend on the laws/regulation that you are under.

Rob Schramm
On May 14, 2013 1:11 PM, Frank Swarbrick frank.swarbr...@yahoo.com
wrote:

 Thank you (and Radoslaw) for your answers.




 
  From: Todd Arnold arno...@us.ibm.com
 To: IBM-MAIN@LISTSERV.UA.EDU
 Sent: Tuesday, May 14, 2013 7:35 AM
 Subject: Re: ICSF master keys at DR site
 
 
 Without a TKE, I don't think there is any other method.
 
 If you do have a TKE, there is a very nice and very secure method of
 completely cloning everything from one crypto card to another one.  This
 was added a couple of releases ago.  Here is the beginning of the
 description from the current TKE user's guide (which I just retrieved from
 Resource Link):
 
 ---
 Configuration migration
 
 The TKE workstation provides tools to securely capture host crypto module
 configuration data to a file, and then reapply this data to another host
 crypto
 module or crypto module group. The data that can be securely captured
 includes
 roles, authorities, domain control settings, and master keys. These tools
 simplify
 the task of installing new or replacement host crypto modules, and can be
 used for
 backup and disaster recovery as well.
 
 Two tools are provided: one that migrates only public configuration data
 (roles,
 authorities, domain control settings) and one that migrates all
 configuration data,
 including secret data, such as master key values. The protocol for
 migrating secret
 data is more complex than the protocol for migrating only public data, and
 requires the participation of several smart card holders.
 ---
 
 Todd Arnold
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


ICSF master keys at DR site

2013-05-13 Thread Frank Swarbrick
I'm pretty sure I know the answer (no), but I just want to make sure.  Is there 
any method other than loading the original key parts that one can load the 
current production keys into a cryptocard at another (DR) site?

No TKE available, if that makes a difference.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ICSF master keys at DR site

2013-05-13 Thread R.S.

W dniu 2013-05-13 23:18, Frank Swarbrick pisze:

I'm pretty sure I know the answer (no), but I just want to make sure.
Is there any method other than loading the original key parts that
one can load the current production keys into a cryptocard at another
(DR) site?


For master key, NO.


No TKE available, if that makes a difference.

No, it doesn't.


BTW: depending on your DR scenario, loading master keys may be a part of 
DR preparation recipe.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN