IBM Destination Z - Group home

Locking Up the Weakest Link in Mainframe Security

By Destination Z posted Mon December 23, 2019 03:42 PM

Everyone knows how important security is in these days of highly organized, perhaps even government-sponsored, attacks on computing platforms. IBM’s new IBM Z mainframe is all about securing information on the mainframe, and has made things very difficult for any hackers to get to see that mainframe’s data. But, at the moment, mainframe users are still using older technology (even as recent as last year’s) and they might not be totally secure. Internally they are pretty secure, but what about the messages sent from the mainframe to remote users and from remote users back to the mainframe?

Nowadays, people are using IP networks to send information, and they need some way to ensure that other people can’t read the data that they are sending. This kind of cryptography has been going on at least since the time of the ancient Greeks. Their generals needed a way to pass on information to their troops that couldn’t be read by their enemies and used simple ciphers. But that technique’s not going to work these days because ciphers aren’t strong enough to stand up under brute force attacks.

One solution to the problem is to use what’s called symmetric key encryption. This allows messages to be sent between users having the same key. Each computer has a copy of the same secret key that it uses to encrypt packets of data before they are sent over a network. The other computer must have the same key on it to decode the data in those packets. In the U.S., the first major symmetric algorithm was the Data Encryption Standard (DES), which used a 56-bit key. That was created in the 1970s. The Advanced Encryption Standard (AES) uses 128-, 192- or 256-bit keys, making it very hard to break.

Another solution is to use public key encryption (also known as asymmetric key encryption). This overcomes the problem of data packets being intercepted between computers because it uses two keys at the same time—a private key and a public key. The private key is known only to one computer, and the public key is given to any computer wanting to communicate securely with the first computer. An encrypted message can be decoded on any computer by the public key (supplied by the originating computer) and its private key. This makes the data very secure even if someone were to intercept the packet because just using the public key isn’t enough, they need to know the private key as well. Brute force attacks won’t work because the key pair is based on prime numbers, which makes it very hard to break. The sending computer encrypts a document with a symmetric key, then encrypts the symmetric key with the public key of the receiving computer. The receiving computer uses its public key to decode the symmetric key, and then uses the symmetric key to decode the document.

SSH is the most commonly used public key encryption. It uses public/private key encryption to authenticate users and machines, to encrypt traffic and to ensure the integrity of data. These SSH keys are almost impossible to decipher because of the way they are created—using prime numbers. Once a key pair has been created, the user has two long strings of characters—one for the public and one for private key. Security can be enhanced by protecting the private key with a passphrase.

Before the public and private keys can be used, they have to be set up. The first step is to create the key pair and then store the keys and the passphrase. The next step is to place the public key on the server and send the private key to anyone who is likely to use it. One issue that many mainframe sites have is that the number of keys created over time can be huge.

Rivest-Shamir-Adleman (RSA) is an algorithm often used to create SSH key pairs. RSA is based on primes and the difficulty of factoring large numbers. It also uses modulo maths. A user generates two large primes, p and q. Let φ = (p-1)(q-1). They pick a number e coprime to φ, and let d ≡ e^-1 mod φ. The public key is then (e, n), while the private key is (d, n). If you’re wondering, two integers are said to be coprime if the only positive integer that divides both of them is 1.

And sticking with the math, a whole number is a composite if it can be obtained by multiplying two smaller numbers together. A prime number can’t be obtained by multiplying two smaller whole numbers together and it is greater than 1. 1 used to be considered to be a prime number, but now it isn’t. Because it’s exceptional, it’s neither a prime nor a composite number. It’s called a unit. All primes (apart from 2) are odd numbers. It’s possible for two numbers that are only two apart to be primes (e.g., 11 and 13 or 17 and 19). These pairs are called twin primes.

Math can be fascinating stuff and it makes SSH very useful. And that has led to SSH being heavily used, but who keeps track of all the SSH keys we mentioned earlier that a mainframe site creates? These SSH keys have been produced at an exponential rate for years. Large enterprises often have several thousands of SSH keys on their systems which never expire. The security issue is that there’s no control of key creation and what those keys are used for. There’s no way to see or manage the keys used for authentication. So SSH keys can be easily created and distributed but extremely difficult to control or track. Companies can’t remove access because they don’t know which applications will break. Even more of a problem for many organizations, the keys aren’t visible to the IT department and never expire. As a result, these SSH keys can provide unauthorized root access to critical production, backup and management servers with the potential to wreak havoc.

A second issue that mainframe sites need to consider is that the lack of SSH key management doesn’t just put an organization at risk from security breaches; it could well make them non-compliant with mandatory security regulations such as Sarbanes-Oxley Act of 2002, Federal Information Security Management Act, PCI and HIPAA. These regulations require proper control of access to servers and termination of that access.

This isn’t a new problem and most sites have software in place to make sure that they aren’t at risk from their network, but like too many things, this security issue gets put on the back-burner as not a priority. However, it’s still well worth checking to make sure that potential networking vulnerabilities are all locked down and SSH keys are being managed.

Trevor Eddolls is CEO at iTech-Ed Ltd, an IT consultancy. A popular speaker and blogger, he currently chairs the Virtual IMS and Virtual CICS user groups. He’s editorial director for the Arcati Mainframe Yearbook, and was an IBM Champion between 2009 and 2016.