subject:"Crypto Facility performance."

Re: Crypto Facility performance.

2013-05-31 Thread Massimo Biancucci

Greg,

you've got the point.

My question was about performance and, depending on what we ask the z12, it
will answer.

So if I ask for a CSNBKEX API (and now I discovered it was clearly written
in the manual) z12 have to use CEX3/4 Coprocessor.

Finally I've found the answer to my main question about the performance (in
terms of crypto/second) per single server (where server is the single
mono-tcb address space calling the API services).

Then, as long as I need CEX3/4 API I have to pay the 1ms elapsed time per
call because there's the need to raise the not so close hardware.

I really thank all of you for your valuable support and knowledge. I've
learnt lots of new stuffs.

Best regards.
Massimo


2013/5/21 Greg Boyd bo...@us.ibm.com

 I'm not sure I understand your last question ... but let me try to clarify
 a couple of things.

 It's important to realize that you have two separate pieces of crypto
 hardware available on System z:
 the CPACF for symmetric clear key and hashing operations and
 the Crypto Express card for symmetric secure key, MAC, public/private key
 operations, Financial/PIN operations, etc.

 There is really no overlap in functionality between the two devices.  Both
 can do symmetric DES/TDES or AES encryption, but the CPACF does the work
 with a clear key, while the CEX card uses a secure key.

 So that means the hardware you need depends entirely on which API you
 specify in your code.  In the ICSF Application Programmer's Guide
 (SA22-7522), each API is documented and includes a 'Required Hardware'
 table at the end of each section.  That table will tell you which piece of
 hardware is required for that API (even down to certain parms require
 certain levels of CCA code in the card).

 If you code CSNBKEX, the Usage Table for that API says that you must have
 a CEX3 or CEX4 Coprocessor on your zEC12 to use that API.

 One note about Protected Key.  To use Protected Key, you use a clear key
 API, but pass a secure key to the API.  Prior to the implementation of
 protected key, this would fail as the clear key APIs can't use a secure
 key.  However, with the protected key support, ICSF will recognize this
 combination and allow the operation to proceed.  In this case, ICSF uses
 both the Crypto Express card to decrypt the operational key from under the
 master key and the CPACF to rewrap the key and then perform the encrypt or
 decrypt of your data (as Todd described).  The 'Required Hardware' table
 refers to protected keys as 'Encrypted Keys'.  So if you want to simply do
 clear key encryption, you only require the CPACF hardware.  But if you want
 to use protected key, then you must also have a Crypto Express card
 (configured as a coprocessor).

 So, in your example, if you use the CSNBKEX API, that implies you have a
 CEX card because that's where the work will be routed.  And if you use the
 CSNBSYE API, you want to use the CPACF hardware.

 You might want to review the 'A Synopsis of Systme z Crypto Hardware'
 Techdoc, available at
 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100810  .

 I hope that helps clarify things.
 Greg Boyd
 IBM Advanced Technical Support
 Supporting Crypto on System z

 --
 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: Crypto Facility performance.

2013-05-21 Thread Greg Boyd

I'm not sure I understand your last question ... but let me try to clarify a 
couple of things.

It's important to realize that you have two separate pieces of crypto hardware 
available on System z:
the CPACF for symmetric clear key and hashing operations and
the Crypto Express card for symmetric secure key, MAC, public/private key 
operations, Financial/PIN operations, etc.

There is really no overlap in functionality between the two devices.  Both can 
do symmetric DES/TDES or AES encryption, but the CPACF does the work with a 
clear key, while the CEX card uses a secure key.

So that means the hardware you need depends entirely on which API you specify 
in your code.  In the ICSF Application Programmer's Guide (SA22-7522), each API 
is documented and includes a 'Required Hardware' table at the end of each 
section.  That table will tell you which piece of hardware is required for that 
API (even down to certain parms require certain levels of CCA code in the card).

If you code CSNBKEX, the Usage Table for that API says that you must have a 
CEX3 or CEX4 Coprocessor on your zEC12 to use that API.

One note about Protected Key.  To use Protected Key, you use a clear key API, 
but pass a secure key to the API.  Prior to the implementation of protected 
key, this would fail as the clear key APIs can't use a secure key.  However, 
with the protected key support, ICSF will recognize this combination and allow 
the operation to proceed.  In this case, ICSF uses both the Crypto Express card 
to decrypt the operational key from under the master key and the CPACF to 
rewrap the key and then perform the encrypt or decrypt of your data (as Todd 
described).  The 'Required Hardware' table refers to protected keys as 
'Encrypted Keys'.  So if you want to simply do clear key encryption, you only 
require the CPACF hardware.  But if you want to use protected key, then you 
must also have a Crypto Express card (configured as a coprocessor).

So, in your example, if you use the CSNBKEX API, that implies you have a CEX 
card because that's where the work will be routed.  And if you use the CSNBSYE 
API, you want to use the CPACF hardware.

You might want to review the 'A Synopsis of Systme z Crypto Hardware' Techdoc, 
available at 
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100810  .

I hope that helps clarify things.
Greg Boyd
IBM Advanced Technical Support
Supporting Crypto on System z

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

Re: Crypto Facility performance.

2013-05-13 Thread Massimo Biancucci

Hi again,

is there anybody who can answer my last (and maybe not least) question ?

Thank you in advance.
Massimo


2013/5/6 Massimo Biancucci mad4...@gmail.com

 Hi everybody,

 I want to thank you for your valuable support anyway I hope you'll have a
 little more patience and give me the final hint.

 What I've understood is that Protected Key is almost as secure as
 Secure Key but the clear everything and more in case of attack.

 Greg said: CSNBKEX (Key Export) and CSNBKIM (Key Import) are both secure
 key APIs, which are executed on the Crypto Express cards

 so, if I well understand, I can do nothing to use the local processor
 and still ICSF will use CryptoCard.

 If so, I can consider closed my trip on the topic.

 If not, do I have to modify my application (I'm expecting - NO) ? Is ICSF
 still doing the work for me (I'm expecting - YES) ? (I think there're
 different stuffs to do at RACF level).

 I'd not want to make my RACF colleagues working on a dead track and
 paying beers for the whole  century ! :D

 Thank you again.
 Massimo Biancucci


 2013/4/30 Todd Arnold arno...@us.ibm.com

  IMHO protected key *does require* CryptoExpress option, not for data
  processing, but for key storing.

 You are right.  The keys are stored in a form that is protected by the
 Crypto Express card.  Crypto Express unwraps the key and passes it directly
 to CPACF.  Thus, Crypto Express is needed in order to use the Protected Key
 CPACF features.

 Once CPACF receives the key from the Crypto Express, it re-wraps the key
 using a key encrypting key (KEK) that it generates.  That key is not
 permanent - it goes away if the system is restarted, etc.  Thus, keys
 wrapped under the CPACF KEK are not suitable for long-term storage, such as
 storage in CKDS.

 At a very high level, it works something like this:

 1.  Key read from CKDS
 2.  Key sent to Crypto Express
 3.  Crypto Express unwraps the key and sends the cleartext key directly
 to CPACF
 4.  CPACF rewraps the key with the volatile KEK it generated when it
 started up
 5.  CPACF returns the rewrapped key to the application program
 6.  Application program uses that rewrapped key in protected mode
 requests to CPACF
 .
 7.  When system is powered off, restarted, etc., the CPACF KEK is lost
 and it generates a new one
 8.  Repeat from step 1

 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: Crypto Facility performance.

2013-05-09 Thread R.S.

W dniu 2013-05-09 02:28, zMan pisze:

Touche. But zEnterprise is a superset of System z, not a distinct
architecture, isn't it?

Wouldn't it be better to stop using marketing names and just be accurate?
I don't care whether z10 is System z or z Series or z/Series.

What I care is z10 is the first machine supporting protected key and
*THAT CHANGED* with the microcode - so first z10's did not support
protected key, but it had changed with further microcode releases.
And I don't think the marketing name was changed with introduction of
the support

--
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: Crypto Facility performance.

2013-05-08 Thread Dave Barry

Ahem...  Did you mean to say zEnterprise?  System z is so last year.  ;-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Saturday, April 27, 2013 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Crypto Facility performance.

zSeries doesn't support Protected Key. Oh, wait,you probably *really* meant 
System z. It's been eight years, time to upgrade your terminology, eh?

On Fri, Apr 26, 2013 at 10:52 PM, Tim Henness ibmm...@henness.org wrote:
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: Crypto Facility performance.

2013-05-08 Thread zMan

Touche. But zEnterprise is a superset of System z, not a distinct
architecture, isn't it?


On Wed, May 8, 2013 at 7:35 PM, Dave Barry dba...@ups.com wrote:

 Ahem...  Did you mean to say zEnterprise?  System z is so last year.  ;-)

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of zMan
 Sent: Saturday, April 27, 2013 9:56 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Crypto Facility performance.

 zSeries doesn't support Protected Key. Oh, wait,you probably *really*
 meant System z. It's been eight years, time to upgrade your terminology, eh?


 On Fri, Apr 26, 2013 at 10:52 PM, Tim Henness ibmm...@henness.org wrote:
 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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: Crypto Facility performance.

2013-04-30 Thread R.S.

W dniu 2013-04-30 06:25, Timothy Sipples pisze:

Scott Ford asks:

I have a question , can a vendor use crypto services on Z
without the crypto Card ?

Lloyd Fuller replies:

Yes, but not protected key.

Protected Key is supported with CPACF (CP Assist Cryptographic Facility)
and does not *require* a CryptoExpress option. Perhaps you meant to write
but not secure key.

According to IBM's documentation Protected Key is available on System z10
(EC and BC) and higher model machines with CPACF enabled (or with
CryptoExpress3 or higher, although I'm not sure if you can have
CryptoExpress without enabling CPACF -- that would be a bit odd). On System
z10 machines specifically you may need to apply a driver update to enjoy
Protected Key support.

What I'm sure, CPACF is prerequisite for CryptoExpress cards.
BTW: CPACF as a hardware is always present, but not always activated.
AFAIR there are two levels of CPACF enablement, first offers SHA and few
other services, the second (FC3863) is prereq for the cards.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Crypto Facility performance.

2013-04-30 Thread R.S.

W dniu 2013-04-30 06:25, Timothy Sipples pisze:
[...]

Protected Key is supported with CPACF (CP Assist Cryptographic Facility)
and does not *require* a CryptoExpress option.

Well, what about CKDS? How the protected keys are stored?
IMHO protected key *does require* CryptoExpress option, not for data
processing, but for key storing.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Crypto Facility performance.

2013-04-29 Thread Phil Smith

Timothy Sipples wrote:
ICSF would be the way to go in terms of maintainability, serviceability,
and related concerns.

I think ICSF allows querying for supported algorithms/hardware to allow
fallback to algorithms that your customer is capable of running. Thus you
should be able to use ICSF to create a program that can run any hardware,
taking exploiting particular customer hardware options should they have
them. (Or maybe ICSF handles those details for you automatically, at least
for certain algorithms.) That's part of the value of ICSF, to abstract from
the underlying hardware details that can vary.

It's certainly easy to look at the Crypto CVT created by ICSF and see what's 
supported. ICSF will automatically fall back when it can-if you call a Secure 
Key API and don't have a CEX, it can't fall back, so that will fail.

...phsiii

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

Re: Crypto Facility performance.

2013-04-29 Thread Todd Arnold

 afterwards ... all corporate
 copying machines were retrofitted with serial number that would appear
 on all copies made.

Ah - I definitely remember the serial numbered copiers, but I never new the 
original reason they did that!  I always figured it was to discourage people 
from using IBM copiers for personal purposes.

 (this was even before DES, coppersmith was still down at
 harvard) 

I really miss being able to contact Don to get quick and accurate answers to 
crypto questions.

Todd Arnold

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

Re: Crypto Facility performance.

2013-04-29 Thread Todd Arnold

 It is *theoretically* possible for someone with physical access to the 
 zSeries processor to open it up and install some customized hardware 
 that could intercept the clear key.  Is that a reasonable risk for the 
 dats you need to protect, when weighed against the improved performance? 
   For most customers I would think so.

The people who put this stuff in the standards all come from a perspective of 
thinking about POS terminals (where you really can attack the hardware), ATMs, 
and injection of keys into HSMs.  In all cases, they're thinking about some 
relatively small hardware device that you can get access to in some way - 
perhaps modifying the hardware, perhaps watching signals flowing over an 
interface, etc.  They are NOT at all thinking of things like internal logic and 
data paths inside a mainframe locked in a secured data center.

I work on some of those standards, and I'm constantly fighting this battle - 
some times I succeed, and some times I don't. 

Todd Arnold

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

Re: Crypto Facility performance.

2013-04-29 Thread John Eells


Phil Smith wrote:


It's certainly easy to look at the Crypto CVT created by ICSF and see what's 
supported.

snip

ICSF also has a query algorithms service that will tell you what's 
supported and whether each algorithm is run in HW or SW on the machine 
the code runs on.  It's a callable service that can also be run from REXX.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Crypto Facility performance.

2013-04-29 Thread Lloyd Fuller

Yes, but not protected key.

Lloyd

- Original Message 
From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, April 27, 2013 2:27:59 PM
Subject: Re: Crypto Facility performance.

Guys,

I have a question , can a vendor use crypto services on Z without the crypto 
Card ?

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

On Apr 27, 2013, at 2:07 PM, Anne  Lynn Wheeler l...@garlic.com wrote:

 paulgboul...@aim.com (Paul Gilmartin) writes:
 This is similar to credit card skimmers in ATMs.  It's *theoretically* 
possible
 but entirely implausible that some such person replace the entire z with a
 counterfeit look-alike ...

 early in the century there was a large pilot deployment of EMV chip
 credit cards in the US ... with an enormous fatal flaw ... even tho
 somebody had pointed out the fatal flaw before the deployment ... they
 apparently didn't understand and went ahead with the deployment
 anyway. When it finally did sink in, all evidence of the pilot
 evaporated ... and contributes to ongoing resistance to repeating
 another deployment in the states. this is somebody's old trip report to
 cartes2002 ... gone 404 but lives on at the wayback machine ... about
 presentation mentioning EMV design flaws (last paragraph)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
l

 after detailed description at an ATM Integrity Task Force meeting,
 somebody made a reference to billions of dollars having been spent to
 proove chips are less secure than magstripe.

 There was myopic attention to countermeasures for lost/stolen card and
 not exposing PIN (authentication information). ATM machines  POS
 terminals would ask the card if the person had entered the correct
 PIN. The problem was that it was trivial to create counterfeit
 chip-cards that were programmed to always answer YES (they became
 known as YES CARDS) ... it was no longer necessary to skim the PIN
 information ... since a counterfeit card would claim everything was
 correct PIN ... regardless of what was entered. misc. past posts
 mentioning YES CARDS
 http://www.garlic.com/~lynn/subintegrity.html#yescard

 part of the design flaw was the card was also asked whether the
 transaction should be done offline; Counterfeit YES CARDS always
 answered YES ... so even if the account was deactivated at the
 financial institution, it had no effect on stopping the transactions.

 during the Future System period in the early 70s ... the vm370
 development group was side-tracked into working on FS ... one of the
 things was a super-security enhanced vm370 so that all super secret
 Future System documents would only be available in softcopy and only
 viewed on specially permitted 3270 screens (the development group had
 outgrown the 3rd flr of 545 tech sq and moved out to the old SBC bldg at
 burlington mall). misc. past posts mentioning science center at 545 tech
 sq http://www.garlic.com/~lynn/subtopic.html#545tech

 part of this was slightly earlier, paper copy of document describing 370
 virtual memory (available for all 370s) showed up at an industry
 publication (before virtual memory for 370 was announced). investigation
 was sort of mini-Pentagon Papers ... afterwards ... all corporate
 copying machines were retrofitted with serial number that would appear
 on all copies made.

 one weekend I had some test time on another machine in the same room.  I
 went by on friday afternoon to get things prepared. they had to show off
 their new super secure machine ... and just had to say that even I
 couldn't break the security ... even if I was left along in the machine
 room over the weekend. so one of the few times I rose to the bait, I
 said it would take only five minutes ... most of the time was spent
 disabling/turning-off all external access to the machine ... and then i
 used the front panel to alter a byte of storage in main memory ... which
 effectively disabled all the system security processes.

 I pointed out that they would would need access authentication for use
 of machine front panel functions ... and could also use encryption for
 all data (this was even before DES, coppersmith was still down at
 harvard) 
 http://en.wikipedia.org/wiki/Don_Coppersmith

 for other topic drift ... some old public key email ... even discussion
 of PGP-like email operation a decade before PGP:
 http://www.garlic.com/~lynn/lhwemail.html#publickey

 MIT leaves behind a rich history in Tech Square
 http://web.mit.edu/newsoffice/2004/techsquare-0317.html

 Research topics also evolved, starting with the grand challenge of
 time-sharing and moving on to new problems as computer science began to
 mature. Tech Square served as the East Coast hub of the ARPANET (it was
 the original Network 18, known today as mit.edu); on the fifth floor,
 Dave Clark's group worked on the infrastructure for what would become
 the Internet, notably the TCP

Re: Crypto Facility performance.

2013-04-29 Thread Lloyd Fuller

Scott,

The newer version of z/PDT support crypto cards.  I am not sure which version 
added it, but I know that the last two or three versions support them.  They 
have to be configured in the zPDT device map.

Lloyd



- Original Message 
From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sun, April 28, 2013 8:38:21 AM
Subject: Re: Crypto Facility performance.

RS,

We use our own encryption routines ..I was wondering if I could make use of 
crypto cards, I am not familiar with them because we develop on Z/Pdt ...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 28, 2013, at 5:44 AM, R.S. r.skoru...@bremultibank.com.pl wrote:

 W dniu 2013-04-27 20:27, Scott Ford pisze:
 Guys,
 
 I have a question , can a vendor use crypto services on Z without the crypto 
Card ?
 
 Please, define vendor and specify what kind of services you mean.
 
 In general every service means some algorithm, most of them also use a key. 
Algorithm can be implemented in your software, but you cannot use so called 
secure keys without crypto cards. There is also CPACF - crypto coprocessor 
which 
speeds up given crypto services, but does not offer secure key.
 
 
 -- 
 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

--
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: Crypto Facility performance.

2013-04-29 Thread Paul Gilmartin

On Sat, 27 Apr 2013 14:07:17 -0400, Anne  Lynn Wheeler wrote:
...
part of this was slightly earlier, paper copy of document describing 370
virtual memory (available for all 370s) showed up at an industry
publication (before virtual memory for 370 was announced). investigation
was sort of mini-Pentagon Papers ... afterwards ... all corporate
copying machines were retrofitted with serial number that would appear
on all copies made.
 
Gee.  Copy it.  Sneakernet it to Kinko's.  Mask serial number and make
second-generation copy.  Or was it a steganographic, highly redundant
serial number?

-- gil

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

Re: Crypto Facility performance.

2013-04-29 Thread Greg Boyd

I think it's important to point out that ANSI X9.24 applies to financial (PIN) 
transactions/data.  And there are federal regulations, at least in the U.S. 
that mandate meeting this requirement of providing tamper resistant/tamper 
responding technology as specified in a number of standards.  The card 
associations and networks also mandate the use of tamper resistant technology.

Other standards do not mandate this technology, however, it is understood in 
cryptography that the key material is secure:  The good guys have access to the 
appropriate keys and the bad guys do not.

With PIN operations, the amount of data being protected is relatively small and 
the performance impact of secure key is acceptable.  However, the performance 
impact may not be acceptable for other applications or processes (for example, 
if you are encrypting a large (multi-megabyte or gigabyte file).  And if  you 
plan on sharing data with a partner, under KeyA, does it really make sense to 
define KeyA as a secure key, if your partner doesn't have secure key 
technology?  The security of the key is only as good as the weakest link.

So, the use of protected keys or even clear keys for other work is certainly 
acceptable, especially when performance is a consideration, as long as you are 
using other techniques to keep that key material away from the bad guys.  
Secure key technology provides the most secure environment for your key 
material and makes key security easier on the key officers.  However, you could 
implement procedures that would compromise that key material.  Similarly, you 
can implement strong procedures that protect your key material even if it those 
keys are defined as clear keys.  (Hint:  secure key technology can help protect 
your data, but it's really your processes and procedures that make the 
difference.)

Customers should use secure key technology when it is mandated or when the 
performance impact is acceptable as balanced against the security requirements 
of the data.  I can imagine environments where the value of the data is 
significant and the performance impact is low, so secure key may be acceptable 
and appropriate.

Protected key provides additional hardware protection for the key material, but 
does not satisfy the tamper-responding technology required for PIN data.  Most 
applications should be using the protected key technology.  For years customers 
have asked about the wisdom of having keys in the clear in the CKDS.  Protected 
key means those keys will no longer be in the clear.

Clear key is still supported and may be appropriate for work that requires the 
absolute fastest performance and throughput.  Especially in environments where 
the data is low value and only exists briefly, clear key is the right solution. 
 For example, System SSL where an attacker would have to capture multiple 
transactions and those transactions only exist briefly on the network, clear 
key is the right technology.

You can compare the performance metrics of clear key, secure key and protected 
key in the performance whitepapers available at 
http://www-03.ibm.com/systems/z/advantages/security/zec12cryptography.html for 
the zEC12 and
http://www-03.ibm.com/systems/z/advantages/security/z10cryptography.html for 
the z10 and z196
(look under 'Learn More' on each page).

Greg Boyd
IBM Advanced Technical Support
Supporting Crypto on System z

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

Re: Crypto Facility performance.

2013-04-29 Thread Timothy Sipples

Scott Ford asks:
I have a question , can a vendor use crypto services on Z
without the crypto Card ?
Lloyd Fuller replies:
Yes, but not protected key.

Protected Key is supported with CPACF (CP Assist Cryptographic Facility)
and does not *require* a CryptoExpress option. Perhaps you meant to write
but not secure key.

According to IBM's documentation Protected Key is available on System z10
(EC and BC) and higher model machines with CPACF enabled (or with
CryptoExpress3 or higher, although I'm not sure if you can have
CryptoExpress without enabling CPACF -- that would be a bit odd). On System
z10 machines specifically you may need to apply a driver update to enjoy
Protected Key support.


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Crypto Facility performance.

2013-04-28 Thread R.S.

W dniu 2013-04-27 20:27, Scott Ford pisze:

Guys,

I have a question , can a vendor use crypto services on Z without the crypto
Card ?

Please, define vendor and specify what kind of services you mean.

In general every service means some algorithm, most of them also use a
key. Algorithm can be implemented in your software, but you cannot use
so called secure keys without crypto cards. There is also CPACF - crypto
coprocessor which speeds up given crypto services, but does not offer
secure key.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Crypto Facility performance.

2013-04-28 Thread Phil Smith

Scott Ford wrote:
We use our own encryption routines ..I was wondering if I could make use of 
crypto cards, I am not familiar with them because we develop on Z/Pdt ...

That's zPDT. And it does full CEX emulation, I believe, so that's actually no 
excuse :)

You can call the CPACF instructions yourself. You can also call ICSF (if it's 
running), and as long as the function you call doesn't *require* a CEX it will 
work.

...phsiii

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

Re: Crypto Facility performance.

2013-04-28 Thread Scott Ford

Phil,

No excuse lie that ...I wasn't sure dude ...so now I can experiment and find 
out ...love it

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 28, 2013, at 8:50 AM, Phil Smith p...@voltage.com wrote:

 Scott Ford wrote:
 We use our own encryption routines ..I was wondering if I could make use of 
 crypto cards, I am not familiar with them because we develop on Z/Pdt ...
 
 That's zPDT. And it does full CEX emulation, I believe, so that's actually 
 no excuse :)
 
 You can call the CPACF instructions yourself. You can also call ICSF (if it's 
 running), and as long as the function you call doesn't *require* a CEX it 
 will work.
 
 ...phsiii
 
 --
 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: Crypto Facility performance.

2013-04-28 Thread Scott Ford

No excuses here ...just curious 

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 28, 2013, at 9:10 AM, Scott Ford scott_j_f...@yahoo.com wrote:

 Phil,
 
 No excuse lie that ...I wasn't sure dude ...so now I can experiment and find 
 out ...love it
 
 Scott ford
 www.identityforge.com
 from my IPAD
 
 'Infinite wisdom through infinite means'
 
 
 On Apr 28, 2013, at 8:50 AM, Phil Smith p...@voltage.com wrote:
 
 Scott Ford wrote:
 We use our own encryption routines ..I was wondering if I could make use of 
 crypto cards, I am not familiar with them because we develop on Z/Pdt ...
 
 That's zPDT. And it does full CEX emulation, I believe, so that's actually 
 no excuse :)
 
 You can call the CPACF instructions yourself. You can also call ICSF (if 
 it's running), and as long as the function you call doesn't *require* a CEX 
 it will work.
 
 ...phsiii
 
 --
 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: Crypto Facility performance.

2013-04-28 Thread R.S.

W dniu 2013-04-28 14:38, Scott Ford pisze:

RS,

We use our own encryption routines ..I was wondering if I could make
use of crypto cards, I am not familiar with them because we develop
on Z/Pdt ...

Well, first you should look at the following manual:
ICSF Application Programmer's Guide SA22-7522
You'll find there are supported crypto services with required hardware
annotations. For real mainframe (contemporary models) your options will
be CPACF and optionally (paid option) CryptoExpress cards.
Then you can compare your routines to those available in ICSF and decide
what can be used. BTW: Some ICSF routines are available without any
crypto hardware.

--
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

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
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.

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

Re: Crypto Facility performance.

2013-04-28 Thread Scott Ford

RS,

Sure will take a look,Ty...this design wasn't mine so I an open to new designs 
and comments.
My preference is easier the better to support, for sure.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 28, 2013, at 9:47 AM, R.S. r.skoru...@bremultibank.com.pl wrote:

 W dniu 2013-04-28 14:38, Scott Ford pisze:
 RS,
 
 We use our own encryption routines ..I was wondering if I could make
 use of crypto cards, I am not familiar with them because we develop
 on Z/Pdt ...
 
 Well, first you should look at the following manual:
 ICSF Application Programmer's Guide SA22-7522
 You'll find there are supported crypto services with required hardware 
 annotations. For real mainframe (contemporary models) your options will be 
 CPACF and optionally (paid option) CryptoExpress cards.
 Then you can compare your routines to those available in ICSF and decide what 
 can be used. BTW: Some ICSF routines are available without any crypto 
 hardware.
 
 
 -- 
 Radoslaw Skorupka
 Lodz, Poland
 
 
 
 
 
 
 --
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
 przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
 jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
 adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
 przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
 rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
 zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
 prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
 usunąć tę wiadomość włączając 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
 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
 Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
 Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości 
 wpłacony) wynosi 168.555.904 złotych.
 
 
 --
 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: Crypto Facility performance.

2013-04-27 Thread zMan

zSeries doesn't support Protected Key. Oh, wait,you probably *really* meant
System z. It's been eight years, time to upgrade your terminology, eh?


On Fri, Apr 26, 2013 at 10:52 PM, Tim Henness ibmm...@henness.org wrote:

 It is *theoretically* possible for someone with physical access to the
 zSeries processor to open it up and install some customized hardware that
 could intercept the clear key.  Is that a reasonable risk for the dats you
 need to protect, when weighed against the improved performance?  For most
 customers I would think so.  But that is something customers have to weigh
 for themselves - with the assistance of their friendly neighborhood auditor!

 Tim


 On 4/26/2013 8:58 AM, Todd Arnold wrote:

 So.. even though the protected key starts with the Crypto Express, it
 wouldn't pass an audit for protection of card data?


 Yes, it STARTS with the Crypto Express, but then the cleartext key is
 protected by the fact that it is buried in the inaccessible System z
 hardware which cannot be seen or probed by applications, the O/S, debug
 tools, etc.  However, regardless of the fact that the key is inaccessible,
 it does not meet the strict requirements as defined by the standards.  As
 an example, here is a piece of the ANSI X9.24 Part 1 standard, which
 defines requirements for handling and managing symmetric cryptographic keys
 in banking applications:

 -- begin text from X9.24.1 ---
 a) Cryptographic keys SHALL only exist in one or more of the following
 forms:
1) In a Tamper-Resistant Security Module (TRSM) as specified in
 Section 7.2 below.
2) If outside a TRSM, as a cryptogram that SHALL have been created
 inside a TRSM by
TDEA using a Key Encrypting Key.
3) If non-encrypted and outside of a TRSM, a key SHALL exist only in
 one of the following
 forms:
  i) as two or more key components as defined in Section 7.5,
 employing dual control
 and split knowledge or
  ii) as a cleartext key while being transferred from a Key Loading
 Device (KLD) to a
 directly connected TRSM
 -- end text from X9.24.1 ---

 Some clarification of terms in this...
- A TRSM is a physically secure device which detects any attempt to
 tamper with it and automatically clears all secret data (like keys)
- TDEA is a synonym for TDES, Triple-DES, which is the only symmetric
 crypto algorithm currently approved for banking applications.
- cryptogram is just a fancy word for a piece of data that is in
 encrypted form.
- key components are values that are combined together to form the
 actual key, such that no component by itself can be
   used to learn anything about the value of the key.  (typically,
 components are exclusive-ored together to create the key.)
- A KLD is a very specialized secure device that can be connected to
 an HSM, Point of Sale terminal, etc. to load keys into it.
- In standards, the word SHALL means that something is absolutely
 mandatory.

 So, this says that any complete key that is not encrypted MUST ONLY exist
 inside a TRSM, which means a physically secure, tamper-detecteing device
 like the Crypto Express.  This is what the auditors are measuring the
 systems against.

 Todd Arnold


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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: Crypto Facility performance.

2013-04-27 Thread zMan

Absolutely, only I'm not sure I'd use that analogy, since skimmers are real
and on the rise!


On Sat, Apr 27, 2013 at 10:52 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 On Fri, 26 Apr 2013 22:52:26 -0400, Tim Henness wrote:

 It is *theoretically* possible for someone with physical access to the
 zSeries processor to open it up and install some customized hardware
 that could intercept the clear key.  Is that a reasonable risk for the
 dats you need to protect, when weighed against the improved performance?
   For most customers I would think so.  But that is something customers
 have to weigh for themselves - with the assistance of their friendly
 neighborhood auditor!
 
 This is similar to credit card skimmers in ATMs.  It's *theoretically*
 possible
 but entirely implausible that some such person replace the entire z with a
 counterfeit look-alike ...

 -- gil

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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: Crypto Facility performance.

2013-04-27 Thread Anne Lynn Wheeler

paulgboul...@aim.com (Paul Gilmartin) writes:
This is similar to credit card skimmers in ATMs. It's *theoretically*
possible
but entirely implausible that some such person replace the entire z with a
counterfeit look-alike ...

early in the century there was a large pilot deployment of EMV chip
credit cards in the US ... with an enormous fatal flaw ... even tho
somebody had pointed out the fatal flaw before the deployment ... they
apparently didn't understand and went ahead with the deployment
anyway. When it finally did sink in, all evidence of the pilot
evaporated ... and contributes to ongoing resistance to repeating
another deployment in the states. this is somebody's old trip report to
cartes2002 ... gone 404 but lives on at the wayback machine ... about
presentation mentioning EMV design flaws (last paragraph)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

after detailed description at an ATM Integrity Task Force meeting,
somebody made a reference to billions of dollars having been spent to
proove chips are less secure than magstripe.

There was myopic attention to countermeasures for lost/stolen card and
not exposing PIN (authentication information). ATM machines POS
terminals would ask the card if the person had entered the correct
PIN. The problem was that it was trivial to create counterfeit
chip-cards that were programmed to always answer YES (they became
known as YES CARDS) ... it was no longer necessary to skim the PIN
information ... since a counterfeit card would claim everything was
correct PIN ... regardless of what was entered. misc. past posts
mentioning YES CARDS
http://www.garlic.com/~lynn/subintegrity.html#yescard

part of the design flaw was the card was also asked whether the
transaction should be done offline; Counterfeit YES CARDS always
answered YES ... so even if the account was deactivated at the
financial institution, it had no effect on stopping the transactions.

during the Future System period in the early 70s ... the vm370
development group was side-tracked into working on FS ... one of the
things was a super-security enhanced vm370 so that all super secret
Future System documents would only be available in softcopy and only
viewed on specially permitted 3270 screens (the development group had
outgrown the 3rd flr of 545 tech sq and moved out to the old SBC bldg at
burlington mall). misc. past posts mentioning science center at 545 tech
sq http://www.garlic.com/~lynn/subtopic.html#545tech

part of this was slightly earlier, paper copy of document describing 370
virtual memory (available for all 370s) showed up at an industry
publication (before virtual memory for 370 was announced). investigation
was sort of mini-Pentagon Papers ... afterwards ... all corporate
copying machines were retrofitted with serial number that would appear
on all copies made.

one weekend I had some test time on another machine in the same room. I
went by on friday afternoon to get things prepared. they had to show off
their new super secure machine ... and just had to say that even I
couldn't break the security ... even if I was left along in the machine
room over the weekend. so one of the few times I rose to the bait, I
said it would take only five minutes ... most of the time was spent
disabling/turning-off all external access to the machine ... and then i
used the front panel to alter a byte of storage in main memory ... which
effectively disabled all the system security processes.

I pointed out that they would would need access authentication for use
of machine front panel functions ... and could also use encryption for
all data (this was even before DES, coppersmith was still down at
harvard)
http://en.wikipedia.org/wiki/Don_Coppersmith

for other topic drift ... some old public key email ... even discussion
of PGP-like email operation a decade before PGP:
http://www.garlic.com/~lynn/lhwemail.html#publickey

MIT leaves behind a rich history in Tech Square
http://web.mit.edu/newsoffice/2004/techsquare-0317.html

Research topics also evolved, starting with the grand challenge of
time-sharing and moving on to new problems as computer science began to
mature. Tech Square served as the East Coast hub of the ARPANET (it was
the original Network 18, known today as mit.edu); on the fifth floor,
Dave Clark's group worked on the infrastructure for what would become
the Internet, notably the TCP/Internet Protocols. Ron Rivest and the LCS
Theory Group did pioneering work in encryption. In 1994, Tim
Berners-Lee, inventor of the World Wide Web, set up the World Wide Web
Consortium's global headquarters on the third floor of Tech Square.

... snip ...

for other total trivia; note that GML had been invented in 1969 at
science center on the 4th flr; a decade later it morphs into ISO
standard SGML; and another decade later it morphs into HTML at
CERN
http://infomesh.net/html/history/early

so it comes full circle with WWW returning to 3rd

Re: Crypto Facility performance.

2013-04-27 Thread Scott Ford

Guys,

I have a question , can a vendor use crypto services on Z without the crypto
Card ?

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

On Apr 27, 2013, at 2:07 PM, Anne Lynn Wheeler l...@garlic.com wrote:

after detailed description at an ATM Integrity Task Force meeting,
somebody made a reference to billions of dollars having been spent to
proove chips are less secure than magstripe.

for other topic drift ... some old public key email ... even discussion
of PGP-like email operation a decade before PGP:
http://www.garlic.com/~lynn/lhwemail.html#publickey

MIT leaves behind a rich history in Tech Square
http://web.mit.edu/newsoffice/2004/techsquare-0317.html

Re: Crypto Facility performance.

2013-04-26 Thread Todd Arnold

 So.. even though the protected key starts with the Crypto Express, it
 wouldn't pass an audit for protection of card data?

Yes, it STARTS with the Crypto Express, but then the cleartext key is protected 
by the fact that it is buried in the inaccessible System z hardware which 
cannot be seen or probed by applications, the O/S, debug tools, etc.  However, 
regardless of the fact that the key is inaccessible, it does not meet the 
strict requirements as defined by the standards.  As an example, here is a 
piece of the ANSI X9.24 Part 1 standard, which defines requirements for 
handling and managing symmetric cryptographic keys in banking applications:

-- begin text from X9.24.1 ---
a) Cryptographic keys SHALL only exist in one or more of the following forms:
  1) In a Tamper-Resistant Security Module (TRSM) as specified in Section 7.2 
below.
  2) If outside a TRSM, as a cryptogram that SHALL have been created inside a 
TRSM by
  TDEA using a Key Encrypting Key.
  3) If non-encrypted and outside of a TRSM, a key SHALL exist only in one of 
the following
   forms:
i) as two or more key components as defined in Section 7.5, employing dual 
control
   and split knowledge or
ii) as a cleartext key while being transferred from a Key Loading Device 
(KLD) to a
   directly connected TRSM
-- end text from X9.24.1 ---

Some clarification of terms in this...
  - A TRSM is a physically secure device which detects any attempt to tamper 
with it and automatically clears all secret data (like keys)
  - TDEA is a synonym for TDES, Triple-DES, which is the only symmetric crypto 
algorithm currently approved for banking applications.
  - cryptogram is just a fancy word for a piece of data that is in encrypted 
form.
  - key components are values that are combined together to form the actual 
key, such that no component by itself can be
 used to learn anything about the value of the key.  (typically, components 
are exclusive-ored together to create the key.)
  - A KLD is a very specialized secure device that can be connected to an HSM, 
Point of Sale terminal, etc. to load keys into it.
  - In standards, the word SHALL means that something is absolutely mandatory.

So, this says that any complete key that is not encrypted MUST ONLY exist 
inside a TRSM, which means a physically secure, tamper-detecteing device like 
the Crypto Express.  This is what the auditors are measuring the systems 
against.

Todd Arnold

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

Re: Crypto Facility performance.

2013-04-26 Thread Phil Smith

Rob Schramm wrote:
When I went thru PCI the first time .. we were talking about putting locks
on the machine doors.  Then we had a conversation with a VISA guy... He
knew exactly what Crypto Express cards were..  and was much more
understanding.

Rob, not sure what you mean here-went thru PCI - you mean a PCI compliance 
audit?

Do you mean that the auditor wanted locks on the machine doors?

And a VISA guy - another auditor?

Not trying to be difficult, just VERY interested in what your experience was!

...phsiii


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

Re: Crypto Facility performance.

2013-04-25 Thread Todd Arnold

 I am having difficulty understand how much less secure protected key
 is from the secure key.

I agree with the comments about this.  The real issue is conforming with the 
very strict requirements written in to banking standards such as ANSI, ISO, or 
PCI.  Basically, they do not approve any implementation that is not inside 
secure, tamper-detecting hardware that clears all keys and other secrets 
immediately if anyone attempts to tamper with it.  Obviously, the hardware and 
low-level firmware in the System z processor do not have that kind of secure 
packaging, whereas the Crypto Express cards to have it.  However, the Protected 
Key implementation keeps all keys and other sensitive information completely 
protected from access by any user, application program, O/S code, etc - so it 
is indeed very, very secure.
 
I always recommend Protected Key when it has the required functions and where 
it's being used for something where your auditor won't say no - and in those 
cases, you have to use the Crypto Express.  Protected Key is an incredibly fast 
solution that really does have very good security.

Todd Arnold
 

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

Re: Crypto Facility performance.

2013-04-25 Thread Rob Schramm

Todd,

So.. even though the protected key starts with the Crypto Express, it
wouldn't pass an audit for protection of card data?

I had thought that the key never appears in the clear at any time with
protected key.  Seems like as long as it never is in the clear that it
would pass muster.  Even with the more esoteric attacks.. if all they get
is the encrypted key... what does it buy them?  Or am I missing something
obvious?

Rob Schramm

Rob Schramm
Senior Systems Consultant
Imperium Group



On Thu, Apr 25, 2013 at 9:32 AM, Todd Arnold arno...@us.ibm.com wrote:

  I am having difficulty understand how much less secure protected key
  is from the secure key.

 I agree with the comments about this.  The real issue is conforming with
 the very strict requirements written in to banking standards such as ANSI,
 ISO, or PCI.  Basically, they do not approve any implementation that is not
 inside secure, tamper-detecting hardware that clears all keys and other
 secrets immediately if anyone attempts to tamper with it.  Obviously, the
 hardware and low-level firmware in the System z processor do not have that
 kind of secure packaging, whereas the Crypto Express cards to have it.
  However, the Protected Key implementation keeps all keys and other
 sensitive information completely protected from access by any user,
 application program, O/S code, etc - so it is indeed very, very secure.

 I always recommend Protected Key when it has the required functions and
 where it's being used for something where your auditor won't say no - and
 in those cases, you have to use the Crypto Express.  Protected Key is an
 incredibly fast solution that really does have very good security.

 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: Crypto Facility performance.

2013-04-25 Thread Phil Smith

Rob Schramm wrote:
So.. even though the protected key starts with the Crypto Express, it
wouldn't pass an audit for protection of card data?

I had thought that the key never appears in the clear at any time with
protected key.  Seems like as long as it never is in the clear that it
would pass muster.  Even with the more esoteric attacks.. if all they get
is the encrypted key... what does it buy them?  Or am I missing something
obvious?

Somebody is, but it isn't you. Remember that auditors typically aren't 
technicians. And their model is PCs. So they get told, Stuff gotta be done in 
an HSM to be considered secure. That's the beginning and the end of the 
conversation. Protected Mode isn't entirely in an HSM (which is what the CEX 
is), so they don't buy it.

Part of their job is not to believe the grizzled veteran who says This stuff 
IS secure. Part of their job might should be-but isn't-to prove that he's 
wrong. But instead, it's just Nope, doesn't fit the rule, can't do it.

Disclaimer: Not all QSAs are this simplistic. But that's the case that causes 
the most problems.

...phsiii

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

Re: Crypto Facility performance.

2013-04-25 Thread Rob Schramm

When I went thru PCI the first time .. we were talking about putting locks
on the machine doors.  Then we had a conversation with a VISA guy... He
knew exactly what Crypto Express cards were..  and was much more
understanding.

Rob.
On Apr 25, 2013 2:14 PM, Phil Smith p...@voltage.com wrote:

 Rob Schramm wrote:
 So.. even though the protected key starts with the Crypto Express, it
 wouldn't pass an audit for protection of card data?

 I had thought that the key never appears in the clear at any time with
 protected key.  Seems like as long as it never is in the clear that it
 would pass muster.  Even with the more esoteric attacks.. if all they get
 is the encrypted key... what does it buy them?  Or am I missing something
 obvious?

 Somebody is, but it isn't you. Remember that auditors typically aren't
 technicians. And their model is PCs. So they get told, Stuff gotta be done
 in an HSM to be considered secure. That's the beginning and the end of the
 conversation. Protected Mode isn't entirely in an HSM (which is what the
 CEX is), so they don't buy it.

 Part of their job is not to believe the grizzled veteran who says This
 stuff IS secure. Part of their job might should be-but isn't-to prove that
 he's wrong. But instead, it's just Nope, doesn't fit the rule, can't do
 it.

 Disclaimer: Not all QSAs are this simplistic. But that's the case that
 causes the most problems.

 ...phsiii

 --
 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: Crypto Facility performance.

2013-04-24 Thread Todd Arnold

Well, I see that I started some interesting discussions.  Let me try to answer 
some of the questions - the answers are not complicated.

Phil Smith said:
 I can only speculate from here that it's either (a) a conservative 
approach, to keep mixed use 
 from causing unsatisfactory performance for one camp or the other (e.g., 
a ton of SSL handshakes 
 causes PIN operations to be slow, or vice versa)

That is exactly the reason.  The System z architects were worried that 
performance would be unpredictable when operations of the two types could 
steal performance from each other.

Tony Harminc said:
 Which of course raises the questions of how well the card interfaces
are documented, and whether the cards are available for other
 platforms.

The low-level interfaces to the cards are intentionally NOT publicly 
documented.  The reason for this is that those interfaces change from time to 
time, typically when we come out with a new card.  Thus, there would be a big 
problem if customers coded to such an interface - they would be quite unhappy 
when their stuff stopped working after IBM made changes.  To solve that 
problem, we define higher-level interfaces (like the CCA API) that we keep the 
same from card to card.
 
The cards are definitely available on other platforms.  It has always been 
available on all IBM server families - for example, see 
http://www-03.ibm.com/security/cryptocards/pciecc/overproduct.shtml where you 
will find information saying the PCIe crypto card (4765, aka CEX3/CEX4S) is 
available on System z (z/OS, Linux, others), Power servers (AIX, IBM i), and 
System x servers (Linux, and Windows by special request).  

Tony also mentioned this:
 Some years ago researchers at Ross Anderson's security lab at Cambridge 
mounted a
 successful attack on earlier IBM crypto APIs

Be careful to understand what they really found.  Their attack was only 
possible in unrealistic configurations in which any user was authorized to 
invoke every API function possible with the crypto card - and in real-world 
systems, access control is always used to block just such attacks.  Prevention 
of such attacks is precisely why there IS access control built in to all 
systems using the crypto cards.  As you may know, even after it was publicized, 
there were never ANY actual cases where such an attack was used on live systems 
- because it was impossible with any reasonably configured system.  Regardless, 
we did make some changes to prevent the attacks they noted.

Radoslaw Skorupka said:
  ... and whether the cards are available for other platforms.
 Yes, obviously. There have been since first model (PCICC).

Actually, it goes back farther than that.  Our first crypto card was the 4755, 
in 1989.  That card was supported on PCs, RISC 6000 AIX systems (predecessor to 
System p and Power), and AS/400.  In addition, we had a separate product, the 
4753, which contained the 4755 card and channel-attached to mainframes running 
MVS.  (and yes, I worked on those - in addition to the research work that 
preceded them.  Thanks, Phil for mentioning my history on this!)

Todd Arnold

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

Re: Crypto Facility performance.

2013-04-24 Thread Rob Schramm

While I understand a certain amount of skepticism about the protected
key.. I am having difficulty understand how much less secure protected key
is from the secure key.  It would seem on the surface that the protected
key is just a child of secure key and still very secure.  Considering the
performance characteristics... it would seem to be quite attractive.

Rob Schramm



Rob Schramm
Senior Systems Consultant
Imperium Group



On Wed, Apr 24, 2013 at 11:00 AM, Todd Arnold arno...@us.ibm.com wrote:

 Well, I see that I started some interesting discussions.  Let me try to
 answer some of the questions - the answers are not complicated.

 Phil Smith said:
  I can only speculate from here that it's either (a) a conservative
 approach, to keep mixed use
  from causing unsatisfactory performance for one camp or the other
 (e.g., a ton of SSL handshakes
  causes PIN operations to be slow, or vice versa)

 That is exactly the reason.  The System z architects were worried that
 performance would be unpredictable when operations of the two types could
 steal performance from each other.

 Tony Harminc said:
  Which of course raises the questions of how well the card interfaces
 are documented, and whether the cards are available for other
  platforms.

 The low-level interfaces to the cards are intentionally NOT publicly
 documented.  The reason for this is that those interfaces change from time
 to time, typically when we come out with a new card.  Thus, there would be
 a big problem if customers coded to such an interface - they would be quite
 unhappy when their stuff stopped working after IBM made changes.  To solve
 that problem, we define higher-level interfaces (like the CCA API) that we
 keep the same from card to card.

 The cards are definitely available on other platforms.  It has always been
 available on all IBM server families - for example, see
 http://www-03.ibm.com/security/cryptocards/pciecc/overproduct.shtml where
 you will find information saying the PCIe crypto card (4765, aka
 CEX3/CEX4S) is available on System z (z/OS, Linux, others), Power servers
 (AIX, IBM i), and System x servers (Linux, and Windows by special request).

 Tony also mentioned this:
  Some years ago researchers at Ross Anderson's security lab at
 Cambridge mounted a
  successful attack on earlier IBM crypto APIs

 Be careful to understand what they really found.  Their attack was only
 possible in unrealistic configurations in which any user was authorized to
 invoke every API function possible with the crypto card - and in real-world
 systems, access control is always used to block just such attacks.
  Prevention of such attacks is precisely why there IS access control built
 in to all systems using the crypto cards.  As you may know, even after it
 was publicized, there were never ANY actual cases where such an attack was
 used on live systems - because it was impossible with any reasonably
 configured system.  Regardless, we did make some changes to prevent the
 attacks they noted.

 Radoslaw Skorupka said:
   ... and whether the cards are available for other platforms.
  Yes, obviously. There have been since first model (PCICC).

 Actually, it goes back farther than that.  Our first crypto card was the
 4755, in 1989.  That card was supported on PCs, RISC 6000 AIX systems
 (predecessor to System p and Power), and AS/400.  In addition, we had a
 separate product, the 4753, which contained the 4755 card and
 channel-attached to mainframes running MVS.  (and yes, I worked on those -
 in addition to the research work that preceded them.  Thanks, Phil for
 mentioning my history on this!)

 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: Crypto Facility performance.

2013-04-24 Thread Phil Smith

Rob Schramm wrote:
While I understand a certain amount of skepticism about the protected
key.. I am having difficulty understand how much less secure protected key
is from the secure key.  It would seem on the surface that the protected
key is just a child of secure key and still very secure.  Considering the
performance characteristics... it would seem to be quite attractive.

Agree 100%. I hope that whoever thought of Protected Key got rewarded 
appropriately: I see it as at least 99.44% as secure (and the missing .56% is 
only because I don't claim to be a crypto expert, not because *I* suspect any 
weakness).

I will note that I was concerned when Protected Key came out that QSAs might 
not accept it as secure. As Monty Python would say, Trouble is, sheep are very 
dim...once they get an idea in their 'eads, there's no shiftin' it. But to the 
best of my knowledge (and I've asked repeatedly) that hasn't happened. 
Protected Key (I almost typed PK, but that's too close to PKI!) has been 
around almost three years now; if there was likely to be significant pushback, 
I'd expect it to be visible by now.

...phsiii

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

Re: Crypto Facility performance.

2013-04-23 Thread Todd Arnold

Let me briefly explain the coprocessor vs. accelerator modes of the CEX 
crypto cards.  As far as the crypto card itself is concerned, there IS no 
difference, and there are no separate modes.  The only difference is how the 
host z machine chooses to use the card.  Let me explain what I mean...

The hardware of the CEX cards provides two different ways to get to the crypto 
services.  

* One is what is called the normal path.  With this, a request from the host 
is formatted into a message block that is sent across the bus to the CEX, where 
it ends up in the card's internal memory.  The microprocessor on the card sees 
that a request has arrived, and processes it - which generally involves quite a 
bit of software (firmware) running on that microprocessor, plus one or more 
operations on the card's crypto hardware chips.  The microprocessor has 
interfaces that let it perform operations using those chips.  Once everything 
is finished, the microprocessor builds a response block in its memory, then 
kicks off a process that sends that response block back to the host.  In 
essence, you can think of normal path as if you were sending a request across 
a network to another computer that has specialized functions - but in this 
case, the network is the PCIe bus and the other computer is the crypto card 
and its processing components.

* The other way is what is called fast path, which you know as accelerator 
mode in the System z.  Using this approach, the host system has a way to 
directly talk to the crypto chips on the CEX card - processing uses ONLY 
hardware and does not involve the CEX microprocessor or any on-card firmware.  
Thus, this is a much faster way of getting to the crypto hardware capability of 
the CEX card - however, it is also very limited in what it can do.  Those 
hardware chips do not implement higher-level things like PIN operations, 
financial key derivations, key management operations, digital signatures, or 
any of the many, many other complex functions you can get through the normal 
path.  It is a trade off - you gain a lot of speed, but lose most of the 
functions the card can perform for you.  Today on System z, fast path is 
mainly used to accelerate the RSA operations that are used to initiate SSL/TLS 
sessions.

The thing most people do not realize is that the CEX card has no problem 
running a mix of normal path and fast path operations - it has hardware 
arbitration logic that lets the host system send any mixture of the two.  Thus, 
there are no separate modes on the CEX itself - as far as it's concerned, you 
can use both modes at the same time.  However, the System z architecture makes 
a distinction between the two modes and only lets you use one of them on a 
given CEX card, according to how you have configured that card into the system.

Todd Arnold

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

Re: Crypto Facility performance.

2013-04-23 Thread Phil Smith

Todd Arnold wrote:
Let me briefly explain the coprocessor vs. accelerator modes of the CEX 
crypto cards.  As far as the crypto card itself is concerned, there IS no 
difference, and there are no separate modes.  The only difference is how the 
host z machine chooses to use the card.  Let me explain what I mean...

The hardware of the CEX cards provides two different ways to get to the crypto 
services.

* One is what is called the normal path.  With this, a request from the host 
is formatted into a message block that is sent across the bus to the CEX, 
where it ends up in the card's internal memory.  The microprocessor on the 
card sees that a request has arrived, and processes it - which generally 
involves quite a bit of software (firmware) running on that microprocessor, 
plus one or more operations on the card's crypto hardware chips.  The 
microprocessor has interfaces that let it perform operations using those 
chips.  Once everything is finished, the microprocessor builds a response 
block in its memory, then kicks off a process that sends that response block 
back to the host.  In essence, you can think of normal path as if you were 
sending a request across a network to another computer that has specialized 
functions - but in this case, the network is the PCIe bus and the other 
computer is the crypto card and its processing components.

* The other way is what is called fast path, which you know as accelerator 
mode in the System z.  Using this approach, the host system has a way to 
directly talk to the crypto chips on the CEX card - processing uses ONLY 
hardware and does not involve the CEX microprocessor or any on-card firmware.  
Thus, this is a much faster way of getting to the crypto hardware capability 
of the CEX card - however, it is also very limited in what it can do.  Those 
hardware chips do not implement higher-level things like PIN operations, 
financial key derivations, key management operations, digital signatures, or 
any of the many, many other complex functions you can get through the normal 
path.  It is a trade off - you gain a lot of speed, but lose most of the 
functions the card can perform for you.  Today on System z, fast path is 
mainly used to accelerate the RSA operations that are used to initiate SSL/TLS 
sessions.

The thing most people do not realize is that the CEX card has no problem 
running a mix of normal path and fast path operations - it has hardware 
arbitration logic that lets the host system send any mixture of the two.  
Thus, there are no separate modes on the CEX itself - as far as it's 
concerned, you can use both modes at the same time.  However, the System z 
architecture makes a distinction between the two modes and only lets you use 
one of them on a given CEX card, according to how you have configured that 
card into the system.

And not that anyone was likely to wonder, Todd is the man in CEX-land-he's the 
father of the IBM crypto architecture.

Thanks for this, Todd. VERY interesting. The fact that System z adds this 
restriction seems odd. I'm sure you would have commented on it if you were able 
to; I can only speculate from here that it's either (a) a conservative 
approach, to keep mixed use from causing unsatisfactory performance for one 
camp or the other (e.g., a ton of SSL handshakes causes PIN operations to be 
slow, or vice versa) or (b) a desire to sell more cards! Any other ideas, folks?

...phsiii

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

Re: Crypto Facility performance.

2013-04-23 Thread Tony Harminc

On 23 April 2013 09:42, Phil Smith p...@voltage.com wrote:

 Thanks for this, Todd. VERY interesting. The fact that System z adds this 
 restriction seems odd. I'm sure you would have commented on it if you were 
 able to; I can only speculate from here that it's either (a) a conservative 
 approach, to keep mixed use from causing unsatisfactory performance for one 
 camp or the other (e.g., a ton of SSL handshakes causes PIN operations to be 
 slow, or vice versa) or (b) a desire to sell more cards! Any other ideas, 
 folks?

One might speculate that it could be harder to prove the
correctness/integrity of the whole system when the card is used in
mixed mode.

Which of course raises the questions of how well the card interfaces
are documented, and whether the cards are available for other
platforms. Can anyone buy one, or only System z customers? Some years
ago researchers at Ross Anderson's security lab at Cambridge mounted a
successful attack on earlier IBM crypto APIs, and I seem to remember
there was a time when they were offering a bounty of some sort for a
new card. It would be interesting to know if IBM has cooperated with
the Cambridge people to evaluate the latest cards and their APIs.

Tony H.

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

Re: Crypto Facility performance.

2013-04-23 Thread R.S.

W dniu 2013-04-23 18:07, Tony Harminc pisze:

On 23 April 2013 09:42, Phil Smith p...@voltage.com wrote:

Thanks for this, Todd. VERY interesting. The fact that System z adds this
restriction seems odd. I'm sure you would have commented on it if you were able
to; I can only speculate from here that it's either (a) a conservative
approach, to keep mixed use from causing unsatisfactory performance for one
camp or the other (e.g., a ton of SSL handshakes causes PIN operations to be
slow, or vice versa) or (b) a desire to sell more cards! Any other ideas, folks?

One might speculate that it could be harder to prove the
correctness/integrity of the whole system when the card is used in
mixed mode.

Which of course raises the questions of how well the card interfaces
are documented

There are NOT documented, which is clearly documented.

, and whether the cards are available for other

platforms.

Yes, obviously. There have been since first model (PCICC). Actually all
mainframe cards are PCI, PCIX or PCIe cards inserted in IBM card case.
The same models were available for other platforms including iSeries,
pSeries and xSeries (PCs). It's called 46xx.

Of course it's nothing specific - OSA cards are also PCI cards (from
Intel) with some additional logic and additional case, not to mention
additional price ;-)

Can anyone buy one, or only System z customers?

Yes, as I wrote above. IMHO you can buy such card even to your desktop
PC, despite of its brand name.

Some years
ago researchers at Ross Anderson's security lab at Cambridge mounted a
successful attack on earlier IBM crypto APIs, and I seem to remember
there was a time when they were offering a bounty of some sort for a
new card.

Can you provide any details? Maybe some link?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Crypto Facility performance.

2013-04-23 Thread Tony Harminc

On 23 April 2013 16:23, R.S. r.skoru...@bremultibank.com.pl wrote:
 W dniu 2013-04-23 18:07, Tony Harminc pisze:

 Which of course raises the questions of how well the card interfaces are 
 documented,

 There are NOT documented, which is clearly documented.

 and whether the cards are available for other platforms.

 Yes, obviously. There have been since first model (PCICC).

But without documentation? Probably hard to use...

 Actually all mainframe cards are PCI, PCIX or PCIe cards inserted in IBM card 
 case.
 The same models were available for other platforms including iSeries,
 pSeries and xSeries (PCs). It's called 46xx.

 Of course it's nothing specific - OSA cards are also PCI cards (from Intel)
 with some additional logic and additional case, not to mention additional 
 price ;-)

Sure, I realize that. But without documentation or at least drivers,
there is little use to a card that complies only with the hardware
standards.

 Some years ago researchers at Ross Anderson's security lab at Cambridge 
 mounted a
 successful attack on earlier IBM crypto APIs, and I seem to remember
 there was a time when they were offering a bounty of some sort for a new 
 card.

 Can you provide any details? Maybe some link?

The best place to start is
http://www.cl.cam.ac.uk/~rnc1/descrack/index.html

Note that despite the URL, this is *not* a general discussion on DES
cracking, but is quite specific to IBM crypto APIs and cards. Note
also that the problems described were fixed long ago (and were
disclosed responsibly to IBM). There are many good links, though a
couple are stale.

Tony H.

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

Re: Crypto Facility performance.

2013-04-23 Thread R.S.

W dniu 2013-04-23 22:49, Tony Harminc pisze:

On 23 April 2013 16:23, R.S. r.skoru...@bremultibank.com.pl wrote:

W dniu 2013-04-23 18:07, Tony Harminc pisze:

Which of course raises the questions of how well the card interfaces are
documented,

There are NOT documented, which is clearly documented.

and whether the cards are available for other platforms.

Yes, obviously. There have been since first model (PCICC).

But without documentation? Probably hard to use...

You asked about System z documentation, not about other platforms. Card
interface for System z is not documented. The only clue for z/OS is use
ICSF (similar for other OSes). It does NOT apply to other platforms.
You can google out and download some documents and AFAIR device drivers.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Crypto Facility performance.

2013-04-19 Thread Peter Vander Woude

One other item for consideration is that the performance, thus response, from 
the CEX will also depend on the encryption algorithm being used.  If you are 
using Triple DES, it will take much longer than if you use AES, even at the 
256bit level.

Peter

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

Re: Crypto Facility performance.

2013-04-19 Thread R.S.

W dniu 2013-04-19 15:56, Peter Vander Woude pisze:

One other item for consideration is that the performance, thus
response, from the CEX will also depend on the encryption algorithm
being used. If you are using Triple DES, it will take much longer
than if you use AES, even at the 256bit level.

For small blocks definitely no. For big blocks - I doubt it.

--
Radoslaw Skorupka
Lodz, Poland

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

Crypto Facility performance.

2013-04-18 Thread Massimo Biancucci

Hi everybody,

we've been installing a new application using crypto facility calling services 
like 'CSNBKEX' or 'CSNBKIM'.

We've done all the possible (in our understanding) to optimize the application, 
so now we can measure more than 150 msg/second per single application server.

What does sound really strange to me is the elapsed time of the two routines 
previsouly mentioned.

Every call costs more than one millisecond.

Cause the CEC is a z12 and the crypto is in HW, I believe those elapsed should 
have been microseconds.

Anybody got a similar experience ?

Thanks a lot in advance.
Max

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

Re: Crypto Facility performance.

2013-04-18 Thread Rob Schramm

Are you setup as secure key or protected key?

Rob Schramm

Rob Schramm
Senior Systems Consultant
Imperium Group



On Thu, Apr 18, 2013 at 6:56 AM, Massimo Biancucci mad4...@yahoo.comwrote:

 Hi everybody,

 we've been installing a new application using crypto facility calling
 services like 'CSNBKEX' or 'CSNBKIM'.

 We've done all the possible (in our understanding) to optimize the
 application, so now we can measure more than 150 msg/second per single
 application server.

 What does sound really strange to me is the elapsed time of the two
 routines previsouly mentioned.

 Every call costs more than one millisecond.

 Cause the CEC is a z12 and the crypto is in HW, I believe those elapsed
 should have been microseconds.

 Anybody got a similar experience ?

 Thanks a lot in advance.
 Max

 --
 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: Crypto Facility performance.

2013-04-18 Thread Phil Smith

Massimo Biancucci wrote:
we've been installing a new application using crypto facility calling services 
like 'CSNBKEX' or 'CSNBKIM'.
We've done all the possible (in our understanding) to optimize the 
application, so now we can measure more than 150 msg/second per single 
application server.
What does sound really strange to me is the elapsed time of the two routines 
previsouly mentioned.
Every call costs more than one millisecond.
Cause the CEC is a z12 and the crypto is in HW, I believe those elapsed should 
have been microseconds.
Anybody got a similar experience ?

It sounds like you think the Crypto Express is for performance. That's a common 
misconception: CEX is for *security*. Calling CEX is essentially doing I/O, so 
it's not cheap, where not cheap means a couple of orders of magnitude slower 
than CPACF, and slower even than just software for most operations. This is 
why I like to say, CEX is not always good (yeah, say it out loud...).

A millisecond for a CEX call doesn't strike me as long at all.

HTH,
--
...phsiii

Phil Smith III
p...@voltage.commailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.comhttp://www.voltage.com/
(703) 476-4511 (home office)
(703) 568-6662 (cell)

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

Crypto Facility performance.

2013-04-18 Thread Massimo Biancucci

Bob,
I'm very ignorant about the topic but your question lighted my steps :D ! 
Thanks a lot.
I asked my colleagues and, as I suppposed before, I think we're in the worst 
case (that should be secure key).
What I think (and hope) is a crypto request to the CP I'm running on should 
respond in micros and not millis.
So I think my request, at the moment, is taken in charge to somebody far from 
my TCB.
It would be very valuable if somebody could share some statistics performance 
data.
What I've read on IBM white paper is that:

It is also important to realize that the application design can have a 
significant impact on 
the performance characteristics. The crypto hardware (CPACF, Crypto Express2 
and 
Crypto Express3) is designed to process large blocks of data. Passing large 
blocks of 
data to be encrypted or decrypted will provide noticeably better performance 
than passing 
small blocks, no matter where the work is done.

that's the opposite of my case, where we encrypt a small piece of data for 
Millions times.
Finally, and it's what I need for the most, is to be sure a millisecond is the 
best I can get, only to avoid getting crazy to find out solutions that don't 
exist (at the moment).
Thanks a lot.
Max

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

Re: Crypto Facility performance.

2013-04-18 Thread Steve Finch

Massimo Biancucci wrote:
we've been installing a new application using crypto facility calling services 
like 'CSNBKEX' or 'CSNBKIM'.
We've done all the possible (in our understanding) to optimize the 
application, so now we can measure more than 150 msg/second per single 
application server.
What does sound really strange to me is the elapsed time of the two routines 
previously mentioned.
Every call costs more than one millisecond.
Cause the CEC is a z12 and the crypto is in HW, I believe those elapsed should 
have been microseconds.
Anybody got a similar experience ?

CPACF is on the CPU chip (hardware). Very fast. While CEX is on a card down in 
the I/O cage, so like Phil said it's like doing an I/O. Very slow (compared to 
CPACF)

CEX (Secure Key) is  so slow, IBM developed Protected Key encryption. It's not 
as secure as Secure Key but it's faster   

A millisecond for a CEX call to encrypt 32 bytes of data is what we got before 
we switched to Protected Key.

Steve Finch
RPS 
--
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: Crypto Facility performance.

2013-04-18 Thread Greg Boyd

I recognize that quote ... it's from my TechDoc WP100647 'A Clear Key / Secure 
Key / Primer Key Primer' on the www.ibm.com/support/techdocs website.  For more 
(better) performance data I would refer you to the Crypto Performance 
Whitepapers.  They are available at:
http://www.ibm.com/systems/z/advantages/security/zec12cryptography.html (for 
the zEC12)
http://www.ibm.com/systems/z/advantages/security/z10cryptography.html (for the 
z10 and z196)
(Look under 'Learn more' on the right for the individual reports.)

I don't believe any of those reports specifically cover the CSNBKEX/CSNBKIM 
APIs, but the report will show the relative performance of the CPACF vs the 
Crypto Express cards.

CSNBKEX (Key Export) and CSNBKIM (Key Import) are both secure key APIs, which 
are executed on the Crypto Express cards.  As Phil pointed out, as a secure key 
device they are more focused on security than performance.  As Radoslaw pointed 
out, when configured as an accelerator the card does provide very good 
performance and throughput, however, the secure key functions are going to 
suffer from latency and data transmission time, getting the work to the card 
and the results back from the card.

Greg Boyd
IBM Advanced Technical Support
Supporting Crypto on System z

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

50 matches

Mail list logo