Re: ICSF key exchange scenario
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 of PKI to handle certification and distribution of the public keys - and for that, you might want to look at the (free) z/OS PKI Services. There are a few things to note. First, remember that a good rule of cryptography is that you should always encrypt a key using a wrapping key of equal or greater strength. If you want to exchange 256-bit AES keys, that is not possible using RSA-based key transport - systems simply do not support RSA keys of that strength. (NIST SP 800-57 says you need a 15,360 bit RSA key to have strength equivalent to a 256-bit AES key.) However, most people are OK using 4096-bit RSA keys to transport any AES key. Another thing to remember is that you can directly encrypt (wrap) a symmetric key using RSA, but you can't do it with Elliptic Curve (ECC). With ECC, you have to use a key agreement algorithm to establish a shared symmetric key-encrypting key (KEK), then use that KEK to encrypt the keys you want to exchange with your partner. (See ICSF verb CSNDEDH, "ECC Diffie-Hellman"). Elliptic Curve also has a method called ECIES (Elliptic Curve Integrated Encryption Scheme) that combines all of this "under the covers" into one operation. However, ECIES has several incompatible variants, and I don't think ICSF has built-in support for it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: An older device query - still using??
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 sorter. Specifically, it was called a "document reader/inscriber", and it read and sorted checks, but with a very important added feature. The 3895 was able to find and read the handwritten amount on a check, then inscribe that amount on the MICR codeline - thus saving a great deal of time over the traditional method where a bunch of operators read the checks with their eyes and type in the amounts on an inscribing machine. I did a lot of work on the OCR that did that recognition - fun stuff. As I recall, the goal was to get it right on at least 50% of the checks, and sort the others out so they could be handled in the traditional way. In addition to these features, the 3895 read the existing MICR codeline data and could print an item number and a bank endorsement on each check. You can see a photo of the machine and a little other information here: http://www.bitsavers.org/pdf/ibm/brochures/IBM3895DocumentReaderInsciber.pdf Secondly, I can confirm that the 3890 sorter used a 360 mod 25 as the internal control unit. This was the case until 1988 (I think), when the 360 was replaced with PC technology. It was quite an interesting process - the team tried for many years to find a replacement for the 360 mod 25, but nothing had fast enough response time to do that until around 1988. That old mod 25 did an amazing job. If I recall correctly, it was programmed directly in its native microcode language, and not in the 360 instruction set. (I should remember for sure, since I wrote some code that ran on that processor, but it was just too long ago...) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> 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 you carry and control yourself, like a smart card or cell phone (maybe even the secure enclave in the phone), and digital signatures can be computed in that same device. The smart card can be PIN-protected, and similarly a cell phone can require authentication. This isn't 100% secure, but it's not bad in most cases - there are several possible attack vectors, but they generally aren't easy. On the mainframe, of course, you can use something like RACF to control access to / use of the private key. Again, not perfect by any means, but not bad. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
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 Curve (ECC) and DSA cannot. (For ECC, there is a method called ECIES that essentially creates a symmetric key under the covers and uses that to encrypt the data.) 3. Someone talked about signing and encrypting. Remember that you should never use the same key pairs for both - you should always have separate key pairs for signing and for encrypting. 4. Phil Smith showed how you can send the same content to multiple people by encrypting it with a symmetric key, then encrypting that symmetric key with each of their public keys. The Cryptographic Message Syntax (CMS) standard (RFC 5652, ANSI X9.73) supports exactly this method using something they call "enveloped data". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
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 with shares you only need a subset. This is typically called an m-of-n scheme, where you create n shares of the key, but any m of those can be combined to form the complete key. This means that you do not need all of the n key share custodians to be present to load the master key - any m of them will do. Note that Crypto Express does not support this for loading the master keys, but I wanted to include it here for completeness. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
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 application keys, and all you need is to restore the master key into a new HSM card - then, all of those application keys will again be usable. There are well-known and well-documented procedures for securely backing up and restoring the master keys. In general, they follow the principles of dual-control and split-knowledge. What this means is that the key value is mathematically broken into two or more separate values, such that none of those tells you anything at all about the value of the complete key. You need to combine them in order to obtain the complete master key. In most cases, the process that is used is to use "key components", which are sometimes called "key parts" - the components must all be exclusive-ored (XORed) together to form the master key, and that XOR only takes place inside the secure HSM card. Each component is protected by a separate person - a key component custodian - who keeps it safely locked up, and who enters it into the HSM when the master key must be loaded or restored. The other key component custodian(s) do the same for their components, and the HSM creates the complete master key inside. The components can be manually keyed in (typically on the smart card reader of a TKE workstation), or they may be stored on electronically-readable media. The preferred method with Z and TKE is to have TKE store them on secure smart cards, and then read them out of those cards when needed. With this approach, the key components are never outside a secure device in cleartext. 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 with shares you only need a subset. This is typically called an m-of-n scheme, where you create n shares of the key, but any n of those can be combined to form the complete key. This means that you do not need all of the m key share custodians to be present to load the master key - any n of them will do. Note that Crypto Express does not support this for loading the master keys, but I wanted to include it here for completeness. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and z/OS 2.3
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Connect:Direct and ICSF (was ICSF and z/OS 2.3)
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and z/OS 2.3
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 the secure CEX HSM. Later on, caching was added in ICSF to create a pool of random data so that the CEX card would not have to be called each time. After that, a new API was added to the CEX card to get a larger batch of random numbers in a single call, again to improve performance. Now, CPACF has been enhanced to make it even faster than it was using CEX. In all of these cases, the random numbers are generated using FIPS-approved methods. One thing that is very nice about ICSF is that it hides all of these lower-level changes from your application programs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crypto Express benefits and alternatives
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 in memory, even though it has things like RACF protection - and there are probably people with authority to remove the RACF protection. When your keys are protected by the Crypto Express HSM, none of those attacks are possible. Once the keys are under protection of the Crypto Express HSM, there is no way to see them except in encrypted form. The HSM has no functions to give you the key in unencrypted form, and any attempt to attack the HSM itself (e.g. opening it and reading its internal memory) will cause immediate destruction of the keys it contains, which makes the externally-stored encrypted keys unusable. So - the amount of security you need depends on your application. For many people, it is sufficient to use CPACF with cleartext keys, where the keys are protected in ways like you described. Other people want more protection, and they use Protected Keys with CPACF - in that case, the keys are protected by the Crypto Express, but they are used by CPACF to give you higher performance. Other people, who want the highest possible degree of security, use the Crypto Express to protect the keys and to perform the cryptographic operations that use them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crypto Utilization Question
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 crypto (e.g. TDES, AES) and for public-key crypto (e.g. RSA, ECC). Thus, your card might be 100% utilized doing TDES operations, but still have lots of capacity to do more RSA operations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption keys and EM waves
> 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 FIPS 140 Security Policy documents, which NIST published on their web site, or the Security Policy documents for products that PCI certifies. For those who are curious, you can find the 4767 (Crypto Express5S) card's FIPS 140 Security Policy here: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3164.pdf. You can find the 4768 (Crypto Express6S) card's PCI HSM Security Policy here: https://www.pcisecuritystandards.org/ptsdocs/4-20333IBM_4768_PCI-HSM_Security_Policy_v1.11-1532367386.40602.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption keys and EM waves
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 / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption keys and EM waves
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and millions of RSA keys
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 million public keys in the PKDS. >2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we >talk about public key, so there is no big reason to keep it secret. >For example: tell ICSF to check msg using given key value, instead of >given key label. I remeber such solution is feasible for symmetric keys >(the key was encrypted using Master Key). Yes, you can store the key tokens outside the PKDS. Callable services accept a label or key token. PKA public keys are in the clear, so there is no security issues. To be clear, I would only recommend keeping public keys outside the PKDS. Private keys should be maintained in the PKDS so they are properly reenciphered during a master key change. >3. What about performance? While DB2 table can be buffered, what about >PKDS? Does it require I/O for every key use? During initialization, ICSF copies the PKDS into 64 bit storage. When a label is passed to a callable service, ICSF retrieves the key token from the in-store PKDS. No I/O is performed during the retrieval -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and millions of RSA keys
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
Re: Intel Chip flaw
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 processes that are protected from each other using hardware features - but a lot of embedded devices only run one process, or run with a model that already lets everything access all memory and resources - since you don't expect people to be adding malicious code to your embedded device. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for mainframe shops Lexington/Cincinnati
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 probably hold out the most opportunities. I did see this job posting for Fort Knox: https://sts-openhire.silkroad.com/epostings/index.cfm?fuseaction=app.dspjob=1317_id=16728=1=3338 Army base in Fort Knox and vendors who facilitate such..." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vector processing instructions
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 64-bits at a time. A full 128-bit value will not fit into a 31-digit decimal number." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Customer is Using CPACF (Crypto) purchased Crypto Express
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 and response - so you have no choice in those cases. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Customer is Using CPACF (Crypto) purchased Crypto Express
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 does, but it can only do a small number of things. - If you need "secure keys" - keys that are protected by hardware that cannot be subverted, even by the highest-technology methods - then use CEX. (but if you need a lower level of security, consider CPACF Protected Key mode.) - If you need the functions that are available only on CEX, then use CEX. Some typical examples are public-key cryptography (CPACF only does symmetric key crypto and hashing) and the wide array of specialized functions required in banking and payment card systems. Sometimes, this means using both CEX and CPACF. SSL/TLS is a good example - this is typically done by using CEX for the public-key operations involved in setting up the session, then using CPACF for the symmetric-key operations used to encrypt/decrypt the session traffic. Often, the SSL/TLS software is designed to do this automatically. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Customer is Using CPACF (Crypto) purchased Crypto Express
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 hardware and its operation. That memory is part of the internal z hardware and is completely separate from any memory that the applications or operating system can see or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Customer is Using CPACF (Crypto) purchased Crypto Express
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 addition to the CPACF? The reason I'd expect is that you want additional security for your keys, but I don't think you've confirmed that. If you use ICSF as the interface, it automatically selects the most appropriate crypto to use - for example, if you are doing clear-key encryption, it will automatically use CPACF because it knows that will be faster than the CEX, but if you want to do PIN block translation it knows it has to use the CEX because the relevant standards mandate that keys can't be in the clear and that the entire translation operation has to be done atomically. Most people find that CEX performance is not good enough for disk encryption applications, so they either use clear-key CPACF or protected-key CPACF, depending on their security requirements on the keys. Performance for protected-key operations is only slightly less than for clear-key ones with CPACF - you can see some performance information in this paper: https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw03283usen/ZSW03283USEN.PDF -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF -CKDS Question
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 CSNBKRC2 to create a new entry in the CKDS with a different label. This will work as long as the customer doesn't have the key store policy control to prevent duplicate tokens in the CKDS enabled. The key store policy controls are documented in the ICSF Administrator's Guide. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GREAT presentation on the history of the mainframe
> 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.wikipedia.org/wiki/IBM_3890) The controller in that sorter was a 360 mod 25, with all the code written in native microcode - no 360 instruction set. It turned out to be very fast, and it was many years before IBM was able to find anything to replace that old mod 25 with its core memory. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches
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=an=897=ENUS217-085 . It has this information about plans to make it easy to keep data encrypted with a minimum of work on the part of the system owner or programmer. = Begin clipped text == New approach to encryption - The threat of data breaches in conjunction with compliance mandates are driving the need for clients to adopt extensive use of encryption across their enterprises. z/OS V2.3 plans to replace application development efforts with transparent, policy-based data set encryption: * Planning enhanced data protection for z/OS data sets, zFS file systems, and Coupling Facility structures to give users the ability to encrypt data without needing to make costly application program changes. * Designing new z/OS policy controls to make it possible to use pervasive encryption to protect user data and simplify the task of compliance. * z/OS Communications Server will be designed to include encryption readiness technology to enable z/OS administrators to determine which TCP and Enterprise Extender traffic patterns to and from their z/OS systems meet approved encryption criteria and which do not. = End clipped text == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches
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 callable services can be called from application programs written in a number of high-level languages as well as assembler. The high-level languages are: - C - COBOL - FORTRAN - PL/I -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Question
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 with your keys). There is a brief summary at this page, but it's quite old and I'm sure there is more current information somewhere: http://www-05.ibm.com/dk/security//products/ekmp-cat.html Here is some summary information from that web page: "The IBM Crypto Analytics Tool (CAT) is part of the IBM Enterprise Key Management Foundation EKMF) and has been developed to help provide up-to-date monitoring of crypto related information on the z Systems in the enterprise. CAT is designed to combine and present crypto information in a way that helps ensure compliance and policy enforcement. The CAT Agent collects cryptographic information across the enterprise that is then made available to the CAT Monitor running on your desktop. The CAT Monitor provides overviews, queries and reports to better manage the cryptographic setup. ... CAT is designed to provide fast, reliable crypto information to help people in different roles of the organization make qualified decisions about crypto systems. CAT collects cryptographic information from across the enterprise and ensures that each crypto system is following best practices by providing: -A comprehensive overview of the cryptographic security of the system. -Up-to-date monitoring of crypto keys and functions. -Key data for better policy and compliance enforcement. -Awareness if key material used in testing has leaked into production environments. -A comparison of the current crypto state with a previous 'snapshot' for error and problem determination or change control validation." Questions about CAT can be addressed to the Denmark team at c...@dk.ibm.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
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=SA=ZSW03283USEN=ZSW03283USEN.PDF It does over 7 million SHA-512 operations per second (per CPU) on 64-byte input data. (That's a rate of 481 MB/sec of hashing. With larger input blocks, the rate gets up to about 3.5 GB/sec.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
> 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 hardware in the CPUs, so I don't think floating point operations are particularly relevant. I certainly would not say a z machine is a good thing to go out and buy just to mine bitcoins, but as others have said it would be an interesting use of spare cycles or unused CPUs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3DES encryption using ICSF callable services
> 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). In addition, CCA has always had clear key "ENCODE" and "DECODE" verbs, but those were intentionally limited to encrypting just 8 bytes of data - the original designers wanted to discourage use of clear key encryption. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3DES encryption using ICSF callable services
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 the appropriate CCA
master key. They are decrypted on the fly inside the HSM and used for the
desired operation. Thus, before you can use a key in the Encipher verb, you
need to get the key into such a form - wrapped by the master key. That's the
purpose of the import operation in the sequence you posted.
With any cryptographic system today, the biggest exposure is protection of your
keys. Hardly anyone actually "breaks" the crypto algorithms themselves - they
find ways to get to the keys.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3DES encryption using ICSF callable services
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 require the attacker to have access to certain information that is generally unavailable in banking transactions, key management, etc. A good reference for what algorithms and key lengths to use (and why) is ISO TR 14742, "Financial services — Recommendations on cryptographic algorithms and their use ". Here is a paragraph from that explaining when 2-key TDES is OK and when it is not: -- begin excerpt -- The recommended end date for use of 2-key Triple DES (TDEA with keying option 1) ranges from 2010 to 2030. Which date is appropriate for a given implementation depends on the way in which the keys are being used in that implementation. If the key usage provides a potential attacker with a large number of plaintext- ciphertext pairs for the same key (e.g. 1,000,000,000,000 ≈ 2**40 pairs), the security of the key is approximately 80 bits and hence the recommended use is until 2010. If only a few (less than 256) pairs are available, it may be acceptable to continue use until 2030. -- end excerpt -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM z Systems Security Conference announcement
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, mobile, social, and cloud computing all have one thing in common: They need a platform that has a deeply integrated security stack. This is where IBM® z Systems™ excel. To help counter the many threats to your business in the current world, including hackers looking to penetrate your systems and government backed attacks, z Systems offers a platform with layers of defense to protect your data, intellectual property, and your reputation. Join us in Montpellier to find out more about how to meet these security challenges with z Systems and discover the new z13 machine and the latest version of z/OS in its version 2.2. Like previous years, we expect more than hundred attendees including Customers, Business Partners and IBMers. Security experts from the IBM z System community and labs will share their experience and expertise. Clients should ask their local IBM representative for an invitation: please see this link for more details: http://www.ibm.com/ibm/clientcenter/montpellier/zsec.shtml Jean Marc Darees Conference Manager If you have any further questions, please contact JM Darees (jmdar...@fr.ibm.com) or Patricia Jimenez (pat_jime...@es.ibm.com). --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CryptoExpress4S - how many domains?
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 System machine needs. The number supported by the machine was determined by deciding what a reasonable number of domains would be, relative to the number of host LPARs and the processing speed of the machine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PCI DSS compliance for z/OS
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 that fails and has to be replaced, that drive still contains your data, but you are unable to talk to it any more - so you have no way to do overwrites to erase the data. If the data was encrypted on the drive, you have no problem - but otherwise, if the vendor requires you to return the failed drive, you have a problem because you're giving someone a copy of whatever data was on that drive when it failed. (If you don't have to return the drive, of course, you can physically destroy it - but that is a pain in the neck to do.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PCI DSS compliance for z/OS
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 route the transaction to the correct issuer, and the last 4 digits are usually required in the clear to be printed on a credit card receipt. In the current ANSI FPE standard (X9.124, which I think is still in draft), the minimum number of PAN digits that get encrypted with FPE is just 6 middle digits. However, it is common to use the other (unencrypted) digits as input to the FPE algorithm, so that cards where these 6 digits are the same do not end up with identical encrypted digits. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PCI DSS compliance for z/OS
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 encryption key never leaves the hardware device in unencrypted form. As I recall, the key is served to the mainframe disk drives using a secure process such that it is never available in the clear. Regardless, it is true that the #1 benefit of encrypted disk and tape drives is the case where the device can be stolen. For tape, the usual example is that someone loses or steals a tape when it is going out of your facility for off-site backup. For disk, the biggest risk scenario is a laptop, which can be stolen or lost. Obviously, it's a lot less likely that someone is going to walk out of your data center with a disk drive that was in use by your mainframe. I think whole-disk encryption has value in all cases, but it has the most value for devices or media that can easily move around. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF and EMV
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 management (and card personalization) using the crypto functions provided in CCA. In general, EMV transactions are protected with a TDES MAC that is computed using a session key. In CCA, this means you must first derive the session key (Diversified Key Generate verb, CSNBDKG) and then you must compute or verify a MAC using the derived key (MAC Generate or MAC Verify, CSNBMGN or CSNBMVR). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
Just for fun, here is a little history of crypto for the mainframe systems. 1977 – IBM 3845 DES encryption unit (channel attached) 1979 – IBM 3848 DES encryption unit (channel attached) - Faster, adds Triple-DES 1989 - IBM 4753 channel-attached crypto unit - uses 4755 crypto adapter internally, first introduction of CCA crypto architecture for System z 1991 – S/390 ICRF (Integrated Cryptographic Facility) - Integrated feature on S/390 for high-speed DES operations using subset of CCA 1997 – S/390 CCF single-chip CMOS crypto replaces ICRF. Adds public-key functions (but no RSA key generation). TKE for secure remote administration. 2001 – zSeries adds the PCICC – a 4758 crypto card under the covers. (4758 had been introduced in 1996 on other IBM platforms) 2001 – PCICA cryptographic accelerator - RSA acceleration - uses 4758 Model 2 crypto chips. Optimized for speed instead of security. 2003 – PCIXCC (4764) Cryptographic Coprocessor - Replacement for 4758/PCICC and PCICA 2003 – CPACF (CP Assist for Cryptographic Functions) added to System z. Integrated into CPUs. Clear key DES/TDES, SHA-1. (other algorithms added in later generations) 2004 - Crypto Express2 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
Hi Todd, Are you saying that the Redbook SG24-7848-00 System z Crypto andTKE Update is just plain wrong ? Actually, I cannot figure out what that text from the RedBook is trying to say :-) All protected-mode keys are stored as CCA secure key tokens, wrapped by the master key of the Crypto Express (CEX) card. The CEX unwraps the key when it is needed by CPACF, which then rewraps it using a temporary CPACF key. That CPACF key is lost whenever the system is restarted, and a new CPACF key is generated at that time. Thus, the only long-term storage of the protected-mode 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. Todd Arnold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
Hi Todd, Are you saying that the Redbook SG24-7848-00 System z Crypto andTKE Update is just plain wrong ? Actually, I cannot figure out what that text from the RedBook is trying to say :-) OK, I looked at the RedBook and I see what it's talking about now. It's sort of a halfway way of using Protected Mode CPACF. You turn your clear keys into protected keys, but the protected key you get is only valid until the next time things are restarted, because at that point CPACF generates a new wrapping key and the protected keys you 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 appropriate for some things where the other mode would not work. Todd Arnold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
Let me add my comments on some of this discussion. ICSF will try to use whatever is best for any particular requested operation. For example, if you want to do a clear-key TDES encryption of some data, it will use the CPACF even if you also have a Crypto Express (CEX) coprocessor. It does that because it knows the CPACF is faster. CPACF is always available (assuming it is enabled in your machine), and ICSF also has built-in software for some things the CPACF does not support. Speed, of course, is not the only factor that must be considered. In many cases, functions that are available in the CEX simply do not exist in CPACF - all of the banking-specific functions such as payment card transaction processing or key management are good examples. Standards (and good security practices) demand that many cryptographic functions be done inside a secure hardware device like the CEX, and similarly many of these demand that keys must never appear in unencrypted form outside of a secure hardware device. One post said It may be ... that the recently announced protected clear keys can be used without a coprocessor, increasing the security level even for clear keys. This is not correct - in order to use the protected keys, you MUST also have a CEX coprocessor. This is because the protection of those keys is actually done through use of the CEX, while the encryption itself is done in the CPACF. Another post said Since z990 (approx. 10 years) you can have crypto cards. Actually, the first one of our crypto coprocessor cards to be supported in the mainframes was the PCI Cryptographic Coprocessor, or PCICC, which was announced on the S/390 G5/G6 machines in 2000. See http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/649/ENUSA00-0293/index.htmllang=enrequest_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 cryptographic performance to G5/G6 servers. Todd Arnold IBM crypto coprocessor development Charlotte, NC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF master keys at DR site
There is/was a way to set a CEX card to allow it to keep the MK loaded while being transferred between machines. Yes, but you also need a TKE to do this. You can enable or disable the crypto card. When the card is disabled, you cannot perform any application-oriented crypto functions with it - for example, encrypting data, managing keys, etc. The only things you can do are the functions related to re-enabling the card, which is done via TKE. While the card is in disabled state, you can remove it from your machine and it will not lose any of the stored data such as the master keys - but you also cannot USE those master keys for anything until the card is re-enabled, and that is not possible except through TKE by two authorized administrators. Here is part of the description that is in the TKE user's manual: -- A crypto module is either enabled or disabled. When a crypto module is enabled, it is available for processing. You can change the status of the module by pressing the Enable Crypto Module / Disable Crypto Module push button. Enable Crypto Module is a dual-signature command and another authority may need to co-sign. Disable Crypto Module is a single signature command. Disabling a crypto module disables all the cryptographic functions for a single crypto module, a group of crypto modules, or a domain group. This disables the crypto module for the entire system, not just the LPAR that issued the disable. -- Todd Arnold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF master keys at DR site
Without a TKE, I don't think there is any other method. If you do have a TKE, there is a very nice and very secure method of completely cloning everything from one crypto card to another one. This was added a couple of releases ago. Here is the beginning of the description from the current TKE user's guide (which I just retrieved from Resource Link): --- Configuration migration The TKE workstation provides tools to securely capture host crypto module configuration data to a file, and then reapply this data to another host crypto module or crypto module group. The data that can be securely captured includes roles, authorities, domain control settings, and master keys. These tools simplify the task of installing new or replacement host crypto modules, and can be used for backup and disaster recovery as well. Two tools are provided: one that migrates only public configuration data (roles, authorities, domain control settings) and one that migrates all configuration data, including secret data, such as master key values. The protocol for migrating secret data is more complex than the protocol for migrating only public data, and requires the participation of several smart card holders. --- Todd Arnold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crypto Facility performance.
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.
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.
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.
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.
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.
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: IBM Mainframe (1980's) on You tube
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 they developed their own APIs and architectures. IBM, of course, had no way to make our own CCA any kind of standard for the industry. (2) Compatibility for interchange has always been a problem, and the solution for key exchange has generally been to use a least common denominator approach, simply wrapping keys with TDES in ECB mode with no associated type/usage information or other metadata. Dissimilar systems generally strip off their proprietary metadata when exporting the key, then the receiving system binds its own proprietary metadata structures to the key when importing it. This obviously is not the best approach in terms of security, but it's what everyone has done all these years. Now, there is the TR-31 key block format which has improved somewhat on that situation, but TR-31 also has significant problems. It defines its own fixed set of key metadata, which of course is not entirely compatible with anything the preceded it and does not generally match up exactly with any vendor's HSM architecture, so translations have to occur and in the process security information is lost or interpreted differently. Furthermore, different vendors have interpreted the meaning of the key type/usage in TR-31 in different ways, so the restrictions you think you defined for a key may not be enforced in quite the way you thought when the key reaches some other device. One example is that TR-31 has rather coarse key typing and usage, whereas CCA has much finer granularity and lets you control the key much more tightly. When translating a CCA key to TR-31 format, all that extra control has to be discarded so that you use only the attributes defined in TR-31. Conversely, when importing a TR-31 key into CCA, you have to somehow create all the extra, more detailed control attributes that are not present in TR-31, and the only way to do that is to let the application program tell CCA what to do. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Mainframe (1980's) on You tube
I've only found ICSF and CCA for Linux on IBM System z. Since CCA is meant to be common I was wondering if it was implemented by anyone outside of IBM itself. I don't know of any non-IBM products that are designed to support CCA, but it is common to all the IBM platforms. You've apparently only found it for the mainframe (ICSF (z/OS) and Linux), but it is also supported - with the same crypto cards - on Power systems running either AIX or IBM i, and on x86 servers running Linux or Windows (although Windows is by special contract these days). 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.ua.edu with the message: INFO IBM-MAIN
Re: IBM Mainframe (1980's) on You tube
IBM had three channel-attached crypto units for the mainframes. 1977 – IBM 3845 DES encryption unit 1979 – IBM 3848 DES encryption unit - faster than the 3845, and added Triple-DES (yes, IBM already had Triple-DES in its products in 1979!) 1989 – IBM Transaction Security System (TSS) which 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 / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Secure Encryption Keys vs Protected Keys
I just discovered this discussion group, and I thought I'd add a little bit of information to the discussion. I am a lead architect in development of the IBM crypto coprocessors (Crypto Express, etc), and in design of the CCA architecture and its verbs. I also happen to have been deeply involved in design of the protected key support. So here are a few random things that might make it clearer. Many of you have made educated guesses, many of which are right, but I wanted to simply state the facts from the viewpoint of someone who should hopefully know them. :-) As described elsewhere, use of protected keys DOES require the Crypto Express coprocessor. The key starts as a secure key (wrapped by the CEX master key). The CPACF firmware sends this to the CEX, where it is decrypted using a special instruction that is not available to normal application programs. The resulting cleartext key is sent directly from the CEX to CPACF and can never appear anywhere in the system that application programs or the O/S can ever see it. Thus, it stays in hardware in the mainframe. This is what makes it much more secure than anything the application program, O/S, RACF, etc. could do - nothing can get to the cleartext key, even though it is in the machine. CPACF generates a fresh wrapping key when it starts, and uses that to wrap the cleartext keys that come back from the CEX. Since that wrapping key will change when CPACF starts up next time, the CPACF-wrapped keys are no good for long term use - they have to be re-decrypted and re-wrapped by CPACF the next time the system starts. Once the key has been unwrapped by the CEX and sent back to CPACF, the CEX is no longer involved in the protected key operations. The CPACF-wrapped protected key gets sent to the CPACF when you need to use it, and the CPACF unwraps it and performs the desired operation. Thus, the protected key operations are extremely fast, but they are slightly slower than clear key CPACF operations since there is an extra step of unwrapping the key. Obviously, if you encrypt a huge block of data, this extra unwrap operation will not have nearly as much impact as if you encrypt a tiny block, since it's only done once for the block in either case. In regard to synchronous vs. asynchronous... This is really from the perspective of the host CPU. A synchronous operation is one like any regular CPU instruction (add, move, etc.). The CPU executes a machine instruction, and at the end of that instruction the result is available. For an asynchronous operation, on the other hand, the CPU executes an instruction that sends a request off for execution somewhere else (hence the name coprocessor), and that CPU instruction is done when the request has been sent. Some time later, the coprocessor notifies the CPU that the request has been completed and the CPU goes and gets it. This asynchronous method is the way the CEX's work. Requests are posted to queues and the CEX's read from those queues, process the work, and return results to the queue. The choice of using protected key CPACF or the CEX is really one dependent on what your application has to do. The protected key CPACF is VERY fast and really is very secure - the only way an attacker could find the value of your key is to attack your mainframe at the hardware level. Nothing they can do in software or with any utilities or management tools will let them attack it. On the other hand, there are several things that would make you use the CEX instead, and they are important. The first one is that the CEX provides a huge and varied set of functions, while the protected key CPACF can only do simple encryption and MAC operations with the keys. The second one is that the protected key CPACF cannot do any kind of enforced key typing or key usage control. For example, you can't specify a key that can only be used for MAC, or one that can only be used to protect financial PINs, or... CCA on the CEX has a rich set of key management and key typing 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 those standards. Todd Arnold Senior Technical Staff Member (STSM) IBM Cryptographic Coprocessor Development (arno...@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: What is the justification for not using Trusted Key Entry (TKE) workstation?
TKE is definitely more secure than the TSO panels. Furthermore, standards that are mandatory for some applications (particularly banking) make the TSO approach unacceptable. Those standards say that you are not allowed to have any cleartext key parts pass through any unprotected general-purpose computer. Since the hardware and software in your general purpose computer is much less secure than the HSM (crypto card) that you are installing keys into, that computer is an easier attack target. The assumption is that smart and capable attackers will capture the key parts as they travel through your mainframe, where they are unprotected, and thus they will not have to find a way to attack the secure HSM itself. In many cases, even the terminal you use to enter the key parts can be easy to attack - for example, keystroke loggers. TKE solves this by using very secure cryptographic protocols for all communications over any unprotected medium. For example, there is strong authentication of the TKE user, and then key parts are strongly encrypted all the way from the crypto module in the TKE workstation to the HSM itself in the mainframe. There is no point where it can be attacked. At the TKE workstation, if you use the optional smart card support, the key parts are entered on the keypad of the smart card reader which is secure, unlike the keyboard on a PC. Note that TKE performs cryptography using its own crypto card (with a special version of the CCA firmware) - something that obviously isn't in an HMC. While I understand why some people think the HMC might be a good place for key loading functions, it does not have the necessary security - for example the embedded crypto card that prevents any cleartext or otherwise sensitive data from passing through the HMC computer or across the network it's connected to. Furthermore, many people want their key management machine locked in a controlled room, while their HMC would not be restricted to the people who need to do key management functions. The question is really what level of 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...@us.ibm.com) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
