The Encrypted File System (EFS) is a J2 filesystem-level encryption through individual key stores. This allows for file encryption in order to protect confidential data from attackers with physical access to the computer. User authentication and access control lists can protect files from unauthorized access while the operating system is running; however, it’s easy to circumvent the control lists if an attacker gains physical access to the computer.
One solution is to store the encrypted files on the disks of the computer. In EFS, a key is associated to each user. These keys are stored in a cryptographically protected key store and upon successful login, and the user's keys are loaded into the kernel and associated with the process credentials. When the process needs to open an EFS-protected file, the system tests the credentials. If the system finds a key matching the file protection, the process is able to decrypt the file key and file content. The cryptographic information is kept in the extended attributes for each file. EFS uses extended attribute Version 2, and each file is encrypted before being written on the disk. The files are decrypted when they are read from the disk into memory so that the file data kept in memory is in clear format. The data is decrypted only once, which is a major advantage. When another user requires access to the file, their security credentials are verified before being granted access to the data even though the file data is already in memory and in clear format. If the user is not entitled to access the file, the access is refused. File encryption does not eliminate the role of traditional access permissions, but it does add more granularity and flexibility.
In order to be able to create and use the EFS-enabled file system on a system, the following prerequisites must be met:
- Install the CryptoLite in C (CliC) cryptographic library.
- Enable the RBAC.
- Enable the system to use the EFS file system.
AIX® EFS encryption is at the file system level. Each file is protected with a unique file key, and protection is created against malicious root.
efsenable command activates the EFS capability on
a system. It creates the EFS administration keystore, the user keystore, and the
security group keystore. Keystore is a key repository that contains EFS security
information. The access key to the EFS administration keystore is stored in the
user keystore and the security group keystore. The
efsenable command creates the /var/efs directory. The
/etc/security/user and /etc/security/group files are updated with new EFS
attributes on execution of this command.
efskeymgr command is dedicated to all key
management operations needed by an EFS. The initial password of a user keystore is
the user login password. Group keystores and admin keystores are not protected by
a password but by an access key. Access keys are stored inside all user keystores
that belong to this group.
When you open a keystore (at login or explicitly with the
efskeymgr command), the private keys contained in this
keystore are pushed to the kernel and associated with the process. If access keys
are found in the keystore, the corresponding keystores are also opened and the
keys are automatically pushed into their kernel.
efsmgr command is dedicated to the files
encryption and decryption management inside EFS. Encrypted files can only be
created on the EFS-enabled JFS2 file systems. Inheritance is set on the file
system or the directory where the file is being created using this command. When
inheritance is set on a directory, all new files created in this directory are
encrypted by default. The cipher used to encrypt files is the inherited cipher.
New directories also inherit the same cipher. If inheritance is disabled on a
subdirectory, the new files created in this subdirectory will not be encrypted.
Setting or removing inheritance on a directory or a file system has no effect on
the existing files. The
efsmgr command must be used
explicitly to encrypt or decrypt files.
Let's take a scenario of a company that has three departments, namely sales, marketing, and finance. These three departments share the same AIX machine to store their confidential content. If EFS is not enabled, the potential of having the data exposed between the three departments is extremely high. See Listing 1 below to learn how to make this threat-prone machine become a safe location to store data.
To enable EFS on AIX, type the following:
Listing 1. EFS enablement in AIX
# efsenable -a Enter password to protect your initial keystore: Enter the same password again:
Enter the following to see the directories created to facilitate EFS:
# cd /var/efs # ls efs_admin efsenabled groups users
All of the EFS capabilities should now be enabled.
You are now going to create a separate file system for all the three departments. The creation of an EFS is similar to the creation of a normal file system. The only difference is that you have to enable the EA2 efs = yes attribute.
Listing 2 illustrates how to create an encrypted file system through the System Management Interface Tool (SMIT):
Listing 2. EFS creation through SMIT
Add an Enhanced Journaled File System Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] Volume group name rootvg SIZE of file system Unit Size Megabytes + * Number of units  # * MOUNT POINT [/sales] Mount AUTOMATICALLY at system restart? no + PERMISSIONS read/write + Mount OPTIONS  + Block Size (bytes) 4096 + Logical Volume for Log + Inline Log size (MBytes)  # Extended Attribute Format + ENABLE Quota Management? no + Enable EFS? yes + Allow internal snapshots? no +
You can also create the same file system through the command line, as shown here in Listing 3:
Listing 3. EFS creation through the command line
#crfs -v jfs2 -g rootvg -m /sales -a size=100M -a efs=yes #crfs -v jfs2 -g rootvg -m /marketing -a size=100M -a efs=yes #crfs -v jfs2 -g rootvg -m /finance -a size=100M -a efs=yes
You have now successfully created three separate file systems for these three departments.
In order to handle or maintain these individual file systems, you need create three different users and create a keystore for them (see Listing 4). (A key store for an user is created when a password is set for that user).
Listing 4. Creation of users
#mkuser salesman #passwd salesman #mkuser marketingman #passwd marketingman #mkuser financeman #passwd financeman
This creates three separate keystores for these three users in the /var/efs/users directory (see Listing 5).
Listing 5. Keystore location for users
# pwd /var/efs/users # ls .lock salesman marketingman financeman root
You can also create keystores for the groups with EFS (see Listing 6).
Listing 6. Keystore creation for groups
#efskeymgr -C finance # pwd /var/efs/groups # ls .lock finance security
Creation of a keystore for a group requires at least one user under it.
This section shows how you can create encrypted files and directories in the EFS file system and manipulate their properties. In order to create EFS directories, you need the EFS file system to be mounted (see Listing 7).
Listing 7. Creating the EFS directory
# mount /finance # cd /finance #mkdir yearlyreport # efsmgr -E yearlyreport # efsmgr -L yearlyreport EFS inheritance is set with algorithm: AES_128_CBC
The yearlyreport directory is now set for inheritance. It indicates that a file or directory inherits both the property of encryption and all encryption parameters from its parent directory.
There are various options with
facilitates you to set the type of cipher to be used on this directory, enable and
disable inheritance, and add or remove users and groups from the EFS access list
of this directory.
In order to carry out any EFS-related activity, you need to load the keystore. If you try to create a file inside this encrypted directory without having access to the keystore that protects it, the following will result:
# cd yearlyreport # ls # touch apr_report touch: 0652-046 Cannot create apr_report.
This happens when you don't have the keystore loaded to perform the EFS activity (see Listing 8).
Listing 8. Loading EFS keystore to the shell
# efskeymgr -o ksh financeman's EFS password: # touch apr_report
Now that you have loaded the keystore, any information that is added to this file is encrypted at the file system level (see Listing 9).
Listing 9. Encrypted file in EFS
# ls -U apr_report -rw-r--r--e 1 financeman system 0 Nov 28 06:14 apr_report
The "e" set for this file means that it's encrypted and no one other than the owner who possesses the key store can access and read its content (see Listing 10).
Listing 10. Listing encrypted file attributes
# efsmgr -l apr_report EFS File information: Algorithm: AES_128_CBC List of keys that can open the file: Key #1: Algorithm : RSA_1024 Who : uid 0 Key fingerprint : 4b6c5f5f:63cb8c6f:752b37c3:6bc818e1:7b4961f9
With the different flags available with the
command, you can change the cipher and other attributes of the file. If you want
to create a file that does not come under any encrypted directory, then you need
to use the following option to encrypt such standalone files (see
Listing 11. Encrypting a single file
#cd /finance #touch companylist # ls -U total 16 -rw-r--r--- 1 root system 8 Nov 28 06:21 companylist drwxr-xr-x- 2 root system 256 Nov 28 05:52 lost+found drwxr-xr-xe 2 root system 256 Nov 28 06:14 yearlyreport # efsmgr -c AES_192_ECB -e companylist # ls -U companylist -rw-r--r--e 1 root system 8 Nov 28 06:24 companylist
Now you have seen that each department has created a separate file system and has a keystore to guard them. If the scenario requests that a person from finance wants to access the encrypted files from sales, then you need to be able to grant him or her permission to do so (see Listing 12 and Listing 13).
Listing 12. vi output when the file is encrypted
#vi sales_report ~ ~ ~ ~ ~ ~ ~ ~ "sales_report" Security authentication is denied.
Listing 13. Passing keystore access to another user
# efskeymgr -k user/salesman -s user/financeman
This command now sends the access key of the "salesman" user to the "financeman" user.
If you try to edit a file owned by
salesman, you can read and access the content in its
plain format, as you now possess the keystore of the user who created the file
(see Listing 14).
Listing 14. vi output after receiving keystore access
#vi sales_report Sales report for this financial year ~ ~ ~ ~ ~ ~ ~ ~ "sales_report" [Read only] 1 line, 36 characters
Instead of sending the complete access key to another user, you can also set access permissions on individual files residing on EFS.
Let's now suppose you have a file in the /marketing filesystem directory and you wish to give access to a particular /marketing/strategy.txt file to the "salesman" user and to the "finance" group. In order to accomplish this task, you need to review Listing 15 and Listing 16.
Listing 15. Granting access to an user
# efsmgr -l strategy.txt EFS File information: Algorithm: AES_128_CBC List of keys that can open the file: Key #1: Algorithm : RSA_1024 Who : uid 0 Key fingerprint : 4b6c5f5f:63cb8c6f:752b37c3:6bc818e1:7b4961f9 # efsmgr -a strategy.txt -u salesman # efsmgr -l strategy.txt EFS File information: Algorithm: AES_128_CBC List of keys that can open the file: Key #1: Algorithm : RSA_1024 Who : uid 0 Key fingerprint : 4b6c5f5f:63cb8c6f:752b37c3:6bc818e1:7b4961f9 Key #2: Algorithm : RSA_1024 Who : uid 204 Key fingerprint : f91b5a79:53bdd7f1:58987a33:f5701a38:99145b24
Listing 16. Granting access to a group
# efsmgr -a strategy.txt -g finance # efsmgr -l strategy.txt EFS File information: Algorithm: AES_128_CBC List of keys that can open the file: Key #1: Algorithm : RSA_1024 Who : uid 0 Key fingerprint : 4b6c5f5f:63cb8c6f:752b37c3:6bc818e1:7b4961f9 Key #2: Algorithm : RSA_1024 Who : uid 204 Key fingerprint : f91b5a79:53bdd7f1:58987a33:f5701a38:99145b24 Key #3: Algorithm : RSA_1024 Who : gid 201 Key fingerprint : 8cb65011:2a42e9f0:91f7b712:20e36bb7:5eb0db0a
If you need to revoke the access that was provided to the
"finance" group, then use the "-r" flag with
efsmgr command, as shown in
Listing 17. Revoking access to a group
# efsmgr -r strategy.txt -g finance # efsmgr -l strategy.txt EFS File information: Algorithm: AES_128_CBC List of keys that can open the file: Key #1: Algorithm : RSA_1024 Who : uid 0 Key fingerprint : 4b6c5f5f:63cb8c6f:752b37c3:6bc818e1:7b4961f9 Key #2: Algorithm : RSA_1024 Who : uid 204 Key fingerprint : f91b5a79:53bdd7f1:58987a33:f5701a38:99145b24
For complete list of flags and options of EFS commands, see the Resources section.
EFS is a great feature presented with AIX 6.1, which helps you encrypt and safeguard your data. This article provided you with basic information on EFS that helps in enabling AIX 6.1 machines with EFS. You learned how to create encrypted files and directories and how to change ciphers and inheritance through commands. You also examined a use case scenario detailing the configuration and usage of EFS.
- Information for System p:
Visit this this site for additional information.
- Check out the following IBM® Redbooks®:
- The AIX 6 Advanced Security Features, Introduction and Configuration Guide—highlights and explains the security features enhancements on AIX 6.1.
- The AIX 5L Version 5.2 Security Supplement—you can use this document as an additional source for security information.
- Popular content:
See what AIX and UNIX® content your peers find interesting.
- AIX and
The AIX and UNIX developerWorks zone provides a wealth of information relating to
all aspects of AIX systems administration and expanding your UNIX skills.
- New to AIX and UNIX?:
Visit the "New to AIX and UNIX" page to learn more about AIX and UNIX.
- AIX Wiki:
A collaborative environment for technical information related to AIX.
- Search the AIX and UNIX library by topic:
- System administration
- Application development
- Tools and utilities
- Java™ technology
- Open source
- Safari bookstore:
Visit this e-reference library to find specific technical resources.
- developerWorks technical events and webcasts:
Stay current with developerWorks technical events and webcasts.
- Podcasts: Tune in and
catch up with IBM technical experts.
Get products and technologies
- IBM trial software:
Build your next development project with software for download directly from
- Participate in the
and get involved in the developerWorks community.
- Participate in the AIX and UNIX forums:
- AIX —technical forum
- AIX 6 Open Beta
- AIX for Developers Forum
- Cluster Systems Management
- IBM Support Assistant
- Performance Tools—technical
- More AIX and UNIX forums
Anto John is an AIX development support specialist for the IBM India Software Labs in Bangalore, India. He works on AIX security components (security library), load modules (LDAP and Kerberos), and new AIX 6.1 security features (EFS). For the past year and a half, he has worked on AIX security components as well as open source components like OpenSSH and OpenSSL. He graduated from BITS Pilani with a Master of Engineering degree in computer science. You can contact him at firstname.lastname@example.org.