Inline. Eric Rossman --------------------------------- ICSF Security Architect z/OS Security ---------------------------------
Radoslaw Skorupka wrote: > W dniu 03.07.2025 o 23:03, Greg Boyd pisze: > > One of the 'more' things that the TKE does is to enforce dual > > controls. That is, it takes two people (and maybe more) to make > > certain changes to the hardware. > > > > Especially the PIN (credit card) related controls, you want that > > dual control. The ACP to enable 24-byte DES-MKs also requires at > > least two people to be involved. And while that might be something > > that you wish was easier to turn on (create a RACF profile to enable > > it), you almost certainly would NOT want to make it that easy to > > turn off. > > Well, I fully understand dual control. However I cannot find any > rationale for dual control over such things like 24-byte MK or some > use of CSNBDKG2 service. Dual control just for dual control is > ridiculous and provide false impression of security. Just because you can't find the rationale does not mean there is none. 24-byte MK was done to prevent unintended consequences and has stuck. Using even 3-key TDES is no longer recommended anyway, so I'm not sure it matters that much anymore. As for CSNBDKG2, think of things like DALL. I could derive a key that can derive any other kind of key and really cause trouble. I'm not a fan of security theater so I wouldn't be defending the design if I didn't understand what it does and why it is worth it. > What secret is protected by limitations of CSNBDKG2? It is key > generate. Wrong. It's not a key generate (despite the naming). It's really a key derivation. > Note, there are no such restrictions when generating clear > keys, Sure, but you are comparing apples to oranges. The expected level of security for PIN processing keys vs key derivation keys vs bulk data keys are all different. > there are RACF profiles for use secure key as PROTECTED - which > can be really considered as lowering the level of security. That is only true for AES 04 (fixed-length tokens) because they had no mechanism to control usage. This is no longer true for AES 05 (var-len). > Dual control plus TKE is needed to change DES-MK to 24-byte (from > 16-byte), but only one person (and no TKE) is needed to zeroize the > key! First change is just configuration, the second is secret data > loss. Apples and oranges. Plus, I already explained the history behind that particular feature. Using TKE to load master keys prevents data leakage which is clearly more dangerous that creating more work (by zeroizing). In a well-controlled area, clearing MK regs should cause no data loss, just a waste of time to reload keys. > Change MK? Just few RACF profiles. No TKE, no dual control Change MK is not as dangerous as the actual loading of key material. The only way a change of MK could happen would be if the key material was able to be loaded, which should be closely controlled in a shop that cares about security. Plus, you could easily use a TKE and have everything you want for security. > (although multi-user controls were implemented in z/OS 3.1 - RACF > controlled, no TKE). And, if you use TKE, you have multi-user control anyway. > Last, but not least: user bought a mainframe with CryptoExpress cards. > However he cannot use 24-byte DES-MK, because he did not buy TKE. And > (again): the user can borrow TKE and press the button for 24-byte > DES-MK, so it is not matter of extra-license, it is matter of missing > knob in the car. You have made your point on this. It has been suggested that you open an IDEA. Feel free to do so. I will tell you now that I will only support moving an IDEA forward if it is worth it from a security standpoint. I am the ICSF architect and I work closely with the CCA and EP11 (and other crypto teams) architects and we extremely interested in ensuring we don't degrade security purely for the sake of "it's easier." ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
