Trusted Solaris implements much stricter controls over UNIX than the standard releases, and is capable of meeting B1 level security by default. It is designed for organizations that handle military grade or commercially sensitive data. In addition to the mandatory use of Role-Based Access Control (as reviewed in Chapter 28), Trusted Solaris actually has no superuser at all: no single user is permitted to have control over every aspect of system service. This decentralization of authority is necessary in situations where consensus and/or authorization are required to carry out specific activities. For example, a system administrator installing a new web server might inadvertently interfere with the operations of an existing service. For a server that’s handling sensitive production data, the results could be catastrophic. Once a system has been installed in production, it’s crucial to define a set of roles that specify what operations need to be performed by a particular individual. For example, the role of managing a firewall is unrelated to the database administration role, so the two roles should be separated rather than being run from a single superuser account. In addition, access to files is restricted by special access control lists, which define file contents as “unclassified” up to “top secret.”
Tip |
Access to data that is labeled as more secret requires a higher level of authentication and authorization than unclassified data. |
There are four roles defined by default under Trusted Solaris for system management purposes: the security officer manages all aspects of security on the system, such as auditing, logging, and password management; the system manager performs all system management tasks that are not related to security, except for installing new software; the root account is used for installing new software; and the oper account is used for performing backups. New roles can be created for other tasks, such as database and web server administration, where necessary.
Some aspects of a Trusted Solaris installation already form part of a standard Solaris installation. For example, Trusted Solaris requires that centralized authentication be performed across an encrypted channel using NIS+—this feature is also available on Solaris, although many sites are now moving to LDAP-based authentication.
One major limitation of symmetric key cryptography is that the same key is required to encrypt and decrypt data. This is fine for protecting individual files from unauthorized users, but many data protection scenarios require multiple users, and in many cases parties amongst which trust has never been established, to be involved. For example, if a manager in New York needed to exchange sales data with a manager in Buffalo, and this data required encryption, then both managers could simply share the key required to decrypt the data. However, this approach has two problems: first, users tend to apply the same password and key to multiple purposes, meaning that one manager might be able to access the other manager’s files; second, what if more than two managers were involved? Clearly, passing a password around a user group of 1,000 users is tantamount to having no security at all! A system is required that allows individual users to encrypt data using one key, and for the file to be decrypted using a separate key for each user.
Asymmetric encryption allows separate keys to be used for encrypting and decrypting data. How is this possible? Basically, every user is assigned a private key, which they never release to anyone else, and a public key, which is supplied to other users who need to send the user encrypted data. For example, the New York manager would have a private key stored on a floppy disk, locked in a safe, as would the Buffalo manager. Both would also exchange their public keys via e-mail, or another offline method such as floppy disk, verifying that the keys were genuine by using a key “fingerprints” check over the telephone. To encrypt a file for the Buffalo manager, the New York manager would need to use both the Buffalo manager’s public key and his own private key. Conversely, the Buffalo manager would need to use her private key and the New York manager’s public key to encrypt a file for him. Remember that if you exchange public keys via e-mail, and have no other method of verifying who is on the other end of the line, then you’re ripe for a “man in the middle attack,” because the person you think you are exchanging data with could be an intermediary. For example, imagine if Joe substitutes his key in place of his manager’s, and manages to place his machine between the manager’s machine and an external router. Now Joe is able to pretend to be his manager, issuing his own public key with his manager’s name for which he actually has the corresponding private key.
The most important feature (or limitation, depending on your requirements) of asymmetric key cryptography is that obtaining the private key used to encrypt data is not sufficient to decrypt that data: only the private key of the individual whose public key was used for signing can be used for this purpose. This can be very important in situations where data may be compromised in a specific location. For example, an embassy in a foreign country under threat of attack may decide to encrypt all data using the public key of an officer in the State Department in Washington, send it via e-mail, and then delete the on-site originals. Even if the encrypted data and the embassy’s private key were obtained by force, they could not be used to decrypt the data.
Of course, asymmetry implies that if you lose your original data accidentally, you must rely on the public-key holder’s private key to decrypt the data. However, at least there is one avenue of recourse available, unlike symmetric key cryptography, where a lost key almost certainly means lost data.
One of the most commonly used “public key” systems that uses asymmetric keys is the Pretty Good Privacy (PGP) application (http://www.pgp.com/). PGP is available for a wide variety of operating systems, making it very popular among PC and UNIX users because data can be exchanged without conversion. PGP works both on the command line, to facilitate secure storage of files, and as a plug-in to e-mail programs, allowing messages to be exchanged securely. This ensures that intermediate mail servers and routers cannot intercept the decrypted contents of transmitted messages, even if they can intercept packets containing the encrypted data.
In order to use PGP, each user needs to generate their own public/private key pair. This can be performed by using the following command:
$ pgp -kg
The following prompt will be displayed:
Choose the type of your public key: 1) DSS/Diffie-Hellman - New algorithm for 5.0 (default) 2) RSA Choose 1 or 2:
The public key format that you choose will determine what types of block ciphers can be used to encrypt your data. The DSS/Diffie-Hellman algorithm allows Triple DES, CAST, or IDEA, while RSA keys will only work with IDEA, so most users will want to select the DSS/Diffie-Hellman algorithm.
Next, you will need to select the key size:
Pick your public/private keypair key size: (Sizes are Diffie-Hellman/DSS; Read the user's guide for more information) 1) 768/768 bits- Commercial grade, probably not currently breakable 2) 1024/1024 bits- High commercial grade, secure for many years 3) 2048/1024 bits- "Military" grade, secure for foreseeable future(default) 4) 3072/1024 bits- Archival grade, slow, highest security Choose 1, 2, 3 or 4, or enter desired number of Diffie-Hellman bits (768 - 4096):
Keep in mind that while a large key provides greater security, it also slows down operations significantly since it is CPU-intensive. Thus, if your needs are really commercial rather than military, you should use the 768- or 1,024-bit key. Military users should certainly select the largest key size available (currently 4,096 bits).
Next, you will need to enter a user ID. This should be recognizable by your intended recipients. For example, a programmer called Yayoi Rei from Rei Corporation would have a user ID of Yayoi Rei <<yayoi@rei.com>>. Even in countries where the family name is usually written first, the expectation for the key server is that the family name will appear last, followed by an e-mail address:
You need a user ID for your public key. The desired form for this user ID is your FULL name, followed by your E-mail address enclosed in <<angle brackets>>, if you have an E-mail address. For example: Joe Smith <<user@domain.com>> Enter a user ID for your public key:
If you wish your key to be valid for a specific time period, you can enter its validity in days next. Alternatively, if the key is intended to be permanent, you can enter zero days:
Enter the validity period of your key in days from 0 - 999 0 is forever (and the default):
A password will need to be associated with the private key for future use, and will need to be entered twice for verification:
You need a pass phrase to protect your private key(s). Your pass phrase can be any sentence or phrase and may have many words, spaces, punctuation, or any other printable characters. Enter pass phrase: Enter again, for confirmation:
Finally, a number of random numbers needs to be generated from the intervals between random key presses on your keyboard. Try to insert some variation in the key press latency to ensure security:
We need to generate 595 random bits. This is done by measuring the time intervals between your keystrokes. Please enter some random text on your keyboard until you hear the beep:
Once the key pair has been created, it is possible to list all of the keys on your local key ring by using the following command:
$ pgp -kl Type Bits KeyID Created Expires Algorithm Use sec+ 768 0x71849810 2002-01-07 ---------- DSS Sign & Encrypt sub 768 0x78697B9D 2002-01-07 ---------- Diffie-Hellman uid Yayoi Rei <<yayoi@rei.com>> 1 matching key found
The key pair is now available for use. In order to generate a copy of your public key for your correspondents and colleagues to use, you will need to extract this from your key ring as follows:
$pgp -x Yayoi -----BEGIN PGP PUBLIC KEY BLOCK----- mQFCBDw5+oURAwDBKeBtW+0PdDvCC7KO1/gUAF9X//uGRhbPkg6m83QzaA7pr6T+ QAVQE4q74NXFCakX8GzmhzHtA2/Hoe/yfpfHGHMhJRZHZIWQWTS6W+r5wHYRSObm NNNTeJ4C+3/klbEAoP/Mjlim4eMkfvYwNmifTUvak5zRAv48SrXOHmVI+5Mukx8Z lT7txut60VeYd34QvidwtUbbL7p2IVVa3fGW/gsuo7whb1aW//+5Z/+4wxbaqnu6 WxT5vFObm1sJ7E20OW3SDLxdVjeTlYbzTUfNwbN/KHoUzMsC/2EZ3aDB6mGZuDPL 0SMT8sOoxlbpPouuBxnF/sbcxgOVKkGZDS5XrhodUbp2RUflwFSMyqjbmoqITnNq xzpSXEhT0odwjjq3YeHj1icBaiy9xB/j0CBXe3QQKAXk5bXMEbQZWWF5b2kgUmVp IDx5YXlvaUByZWkuY29tPokASwQQEQIACwUCPDn6hQQLAwECAAoJEHCOVqNxhJgQ riMAn18a5kKYaepNk8BEksMJOTbRgDQmAKC0JD6wvYfo5zmziGr7TAv+uFWN5LkA zQQ8OfqHEAMA6zd3dxeMkyKJmust3S3IrKvQzMLlMoRuQdb+N2momBYDF1+slo8k EMK8F/Vrun+HdhJW+hWivgZRhTMe9fm6OL7PDYESkwuQsMizqAJJ1JF0yhbfTwE5 GjdVPcUMyPyTAAICAwCgdBO1XyiPbwdQtjxq+8CZ7uchASvJXsU28OFqbLzNcAW2 Q64lWSs6qr2HNfgf+ikG8S8eVWVKEBgm6md9trr6CK25SYEu4oB3o1f45X4daa/n iNytKUglPPOJMK/rhJOJAD8DBRg8OfqHcI5Wo3GEmBARAs3mAJ0ZPQjmlYyNsMDY ZVbR9/q2xQl8gACgkqVCNYR40mPIaxrd5Cw9ZrHqlkQ= =Gsmt -----END PGP PUBLIC KEY BLOCK-----
To encrypt a file using standard, symmetric encryption, you simply pass the –c option on the command line along with the name of the file that you want to encrypt. This provides Solaris users with an alternative to crypt, where a more secure encryption algorithm is desired:
$ pgp -c secret.doc You need a passphrase to encrypt the file Enter pass phrase: Enter same passphrase again Enter pass phrase: Creating output file secret.pgp
After entering a password to protect the data in secret.doc, the encrypted file secret.pgp is created. In order to sign the file for another user, the –e option needs to be passed, along with the name of the user from your key ring who will have the power to decrypt your data:
$ pgp -e Henry secret.doc 4096 bits, Key ID 76857743, Created 2002-01-07 "Henry Bolingbroke <<henry@bolingbroke.co.uk>>" Creating output file secret.pgp
The file can then be transmitted to Henry by UUencoding it, sending it as an e-mail attachment, or by directly generating the file in ASCII format:
$ pgp -ea Henry secret.doc