That is a very, very common scenario, and ICSF has API functions (verbs) to
support it. Have a look at the Symmetric Key Export and Symmetric Key Import
verbs (and their enhanced relatives Symmetric Key Export 2 and Symmetric Key
Import 2). Doing this, of course, requires you to have some kind
I just ran across this thread, and thought I'd correct/confirm a couple of
things. I spent the first part of my IBM career on the development team that
designed the 3890 and 3895, so I am familiar with those machines.
First, the 3895 was NOT a printer. It was a specialized kind of check sort
> crypto non-repudiation can show it came from your machine
I certainly agree with this, but you can restrict what "your machine" is so
that it's a lot better than just "came from a particular PC" or "came from a
particular mainframe". For example, the private key may be stored in something
yo
A few random comments about this discussion:
1. Someone mentioned performance. If that is a concern, use hardware to do
the public-key algorithm - for example the Crypto Express HSM.
2. Remember that not all public-key algorithms can directly encrypt data. For
example, RSA can, but Elliptic
Correcting a couple of careless "n" and "m" typos in my previous post...
--
Another, similar approach that is sometimes used is to use "key shares" instead
of components. The difference is that with components, you must combine ALL of
the components to form the master key, but wi
The master keys, which are stored securely inside the Crypto Express HSM and
can never be extracted, are the top-level keys in the key hierarchy. Your
application-level keys are stored outside the HSM, encrypted by the master
keys. Thus, if the HSM fails, you still have the externally-stored a
I'm afraid I can't help on that end. I'm an expert in the HSM (I've been
developing them since the first IBM HSM started as a research project in the
1980s), but not in ICSF releases. Hopefully, someone else will know the
answers to your questions.
In particular, you don't get any of the financial crypto verbs without a Crypto
Express. The standards do not allow banks to perform functions like those
unless they are executed in a physically and logically secure crypto device.
There have been several changes over the years to improve performance of random
number generation, but the important thing is that the random numbers were
always generated using secure methods. As Greg mentioned, ICSF started using
the CEX long ago to get random numbers, which were generated in
As Radoslaw says in his post, RACF and the usual Z host security is indeed
very, very good, but they do not protect you against everything. For example,
an insider attack by a sufficiently-authorized person could disclose keys
protected by RACF - there are people who can get to data on disk or
Unfortunately, crypto card utilization is a complex thing because the HSM cards
themselves can execute multiple operations simultaneously, depending on the mix
your applications are sending it. A simple example is the fact that the cards
have completely independent hardware for symmetric key cr
> Are the specific results of the various tests a available to review?
Not to my knowledge. Generally, the only thing that is public is a binary
"yes/no" on the test results, and some (often detailed) description of the
product's features that were tested. For examples of the latter, see the F
For things like FIPS 140, IBM does its own testing before we send anything to
the independent lab for them to test. Then, the lab does their own testing for
the formal certification.
--
For IBM-MAIN subscribe / signoff / archiv
High-end crypto devices like the Crypto Express cards already have a lot of
what you'd think of as Tempest protection. In fact, the FIPS 140 Level 4
evaluation (which all Crypto Express cards pass) includes verification that
those kinds of side-channel attacks are prevented.
--
Here are the answers from my friends on the ICSF development team.
>1. Is it good idea to have millions of keys in PKDS? Would it be a
>problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF
>have some bottlenecks or limitations.
There will be no problem for ICSF to store 2 to 3
I sent this question on to someone on the ICSF development team.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Remember that in order to exploit these, you need to be able to load and run
your own code next to the code you're trying to attack. You generally can't do
that in embedded devices like printers, routers, POS terminals, etc. Also,
these are attacks that apply to systems running multiple proces
I asked some IBM coworkers of mine who are located in Lexington. Here's what
they had to say:
"One person thought of the University of Kentucky here in Lexington. Also, in
Central Kentucky, I know of NTT Data (Frankfort), Booz Allen (Radcliff), and
Humana (Louisville). Louisville/Cincinnati pr
I got this answer from someone else at IBM, who is an expert in the vector
instructions:
"Currently to convert a 128-bit singed/unsigned integer in a vector register to
a packed decimal value you must store the value to memory and use the standard
integer conversion instruction CVBG to convert 6
Right - the CPACF Protected Keys are *very* secure and we were very happy with
our ability to add that feature. Unfortunately, for some applications (such as
payment card systems), the standards require a "Secure Cryptographic Device"
(SCD) like an HSM that has advanced active tamper detection
So, the discussion about ICSF is not meaningful - ICSF runs on z/OS, and you're
not using z/OS in this case.
In general, the choice between CPACF and CEX is fairly straightforward.
- If the function(s) you need can be done with CPACF, then use CPACF.
It is faster than CEX for everything it
As Phil said:
> (arguably the firmware is slightly less secure than the tamper-resistant HSM,
> but the memory
> used in the firmware to hold that key is protected-it's apparently not even
> visible in HMC dumps)
That is correct. The memory where the key is held is associated with the CPACF
h
Since I design some of this stuff, I can help clarify - but others have already
done a pretty good job of explaining the various alternatives.
What I'd like to ask is what you are actually trying to do? What is the reason
for installing the Crypto Express and trying to use it instead of or in
I asked one of the ICSF developers about this. Here is his reply:
--
There is no way to create a new entry in the CKDS from an existing entry using
KGUP.
The way I would do it would be to write a program to do the following:
• Call CSNBKRR2 to get the key token
• Call CSNB
> 303x external channels (channel director) was 158 engine with integrated
> channel microcode (and no 370 microcode).
360 processors with special microcode were used in a number of things. Early
in my career, I worked on development of the IBM 3890 high-speed check sorter.
(https://en.wikiped
A good example of how z System is keeping up with encryption and making it even
easier to use can be seen in the brief summary in "Preview: IBM z/OS Version 2
Release 3" at
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&supplier=897&letternum=ENUS217-085
. It has this
Gee, I've been developing crypto technology for 30+ years that runs in those
environments - so it's certainly news to me that it can't be done :-)
Looking at the ICSF Application Programmer's Guide, which defines the ways most
z/OS applications get cryptographic services, I see this:
ICSF ca
You might want to look at the IBM Crypto Analytics Tool (CAT), offered by the
excellent IBM crypto team in Denmark. It is intended to analyze your crypto
system and provide a variety of reports on many things you might need for
system management, compliance, etc. (including things having to do
Kirk, you don't need to program the SHA-256 algorithm in software - it's
available as a hardware instruction using CPACF. I don't have performance
numbers handy for SHA-256, but you can see SHA-512 performance in this paper:
http://www.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA
> z/Series machines are not geared towards floating point operations the way
> commodity GPUs, FPGAs, or purposely built BitCoin miners are.
Remember that the main thing you need to do for bitcoin mining are hashing
operations. The z machines have the hash algorithms built in to the CPACF
hard
> Actually ICSF provides both open and secure key encryption services.
Yes - mainly, those were added so that applications would have a way to use
ICSF for clear-key encryption with the CPACF. Those were not originally a part
of CCA, and are not supported in the HSM cards (Crypto Express, 476x)
One of the fundamental design points for CCA is that keys are protected. Once
they are inside the CCA system, they are always encrypted if they are outside
the physically secure HSM module. Thus, most crypto functions in the CCA API
("verbs") only accept keys in encrypted form - wrapped with t
I'd like to point out that 2-key TDES is still the standard for banking
cryptography and that almost nothing in payment card or related security uses
anything else - in fact, some standards (like DUKPT) do not support 3-key TDES
at all.
The confusion is because the best attacks on 2-key TDES r
I received an email announcing this event and thought some readers might be
interested. Here is the note:
---
Dear All,
Join us for the IBM z Systems Security Conference which will be held September
27th to October 2nd at the IBM Client Center Montpellier, France.
Analytics,
> 16 was the number for a long time. Also, why 85? 5 x 17? Where did the
> extra 1 come from? I would have expected ... 5 * 16 = 80
The number of domains architecturally supported in the CEX5 card itself is
actually 256, which is of course a nice power of 2. However, that is more than
that z
> I think much of the problem is with credit card numbers themselves. There are
> only ~10**16 possible credit card numbers...
Actually, it's much worse than that. You can't encrypt all of the PAN for a
credit card. Typically, the first part (the BIN) is required in cleartext in
order to rout
Phil Smith wrote:
> ... and when decommissioning hardware-no more "How many DSEs should
we > do? or "Should we take the drives out back, shoot ‘em with a
12-gauge, > and then drop ‘em in the ocean?".
Actually, there is a much more interesting corollary to this scenario. If you
have a drive th
The article you referenced seems to assume whole-disk encryption is always
implemented using software on your computer, since it says "the operating
system has the decryption key to access the disk". That is not true, of
course, for self-encrypting disk drives (or tape drives) where the encrypt
IBM is aware of the difficulty figuring out what combination of CCA verbs to
use for each EMV function, and we are working on things to make this easier.
However, all of the necessary functions are definitely there in CCA - we have
many customers who process EMV transactions and perform EMV key
ou got from it earlier become invalid. This is in
contrast with the "full" protected mode which uses a CEX card, and where your
keys are stored in CEX key tokens that are still good after restarts.
Both are good, valid approaches, but obviously the "full" approach is
approp
keys is under the CEX master keys. Those can't be used, of course, unless you
have the CEX. Thus, a CEX is required in order to use protected-mode CPACF.
If you take a clear key and import it to protected mode, the result is a
protected key that cannot be used without having a CEX
introduced
2009 – Protected Key CPACF
2009 - Crypto Express3 (4765 card) replaces PCIXCC
2012 - Crypto Express4S - same crypto card as Crypto Express3, but packaged
differently for new mainframes
Todd Arnold
IBM Cryptographic Coprocessor Development
Charlotte, NC
ocURL=/common/ssi/rep_ca/3/649/ENUSA00-0293/index.html&lang=en&request_locale=en
for one of the announcement notices, which says in part: "New for 2000, the
IBM PCI Cryptographic Coprocesser (PCICC) is an orderable feature that adds
additional cryptographic function and cryptographi
e system, not just the LPAR that issued the disable.
--
Todd Arnold
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
quires the participation of several smart card holders.
-------
Todd Arnold
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
t 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
ork 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...@li
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
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 em
quired 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 g
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
te "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 c
us to send more data to the crypto card at a
time - meaning there are fewer calls to the card than on System z, where it is
chopped into smaller packets.
Todd Arnold
IBM Cryptographic Coprocessor development
--
For IBM-MAIN subs
Two points...
(1) Remember that when IBM invented CCA back in the late 1980s, there really
were no other HSMs - thus, there were no other crypto architectures in the
banking world to be "compatible" with. I suppose other vendors who came along
and developed HSMs could have adopted CCA, but th
).
You can find some info on the cards and CCA for those systems starting at
http://www.ibm.com/security/cryptocards.
- Todd Arnold
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv
f security is appropriate (or required) in
your particular application. There is no question that TKE is much more
secure, but for many people the TSO panels are perfectly acceptable.
Todd Arnold
Senior Technical Staff Member (STSM)
IBM Cryptographic Coprocessor Development
(arno...@
features that do that.
Finally, if you are doing any kind of bank card or payments processing, or some
other operations, there are standards that make it mandatory that you use an
HSM like the CEX cards. Even though protected key CPACF is very secure, it
does not meet the rules stated in tho
included the 4753. The 4753
was the first product to offer the CCA architecture, and it is the ancestor of
all of the other crypto processors such as the Crypto Express cards.
Todd Arnold
--
For IBM-MAIN subscribe / signoff
58 matches
Mail list logo
