Layered security is often described as the practice of combining multiple mitigating security controls to protect resources and data. For example a properly configured service on a server may not prevent an intrusion if the server or the network does not have a securely configured firewall. One such security layer which is sometimes ignored is hard disk encryption. This is an additional layer on top of physical security of the device, i.e. it provides additional protection in case the device (server or laptop) is stolen.
LUKS serves as a standard for Linux hard disk encryption. By providing a standard on-disk-format, it not only facilitates compatibility among distributions, but also provides secure management of multiple user passwords. LUKS stores all necessary setup information in the partition header, enabling the user to transport or migrate data seamlessly.
For server devices which are always connected in a network, NBDE or Network Bound Disk Encryption is a solution which allows system administrators to manage LUKS encrypted disks remotely. The concept is simple: a client with a LUKS mount makes a remote call to a decryption key server. If the keys match, the mount happens without human interaction!
However there is no such management solution for laptops and a combination of LUKS based encryption and password or key based encryption is the only solution available. This however poses some interesting issues when deploying Linux on laptops in a corporate based environment.
-
Employees sometimes forget their passwords. This is especially a problem with LUKS passwords, since they cannot be controlled by a central authentication service like Kerberos, etc.
-
If employees leave the company in a hurry, or turn hostile, and you need to get access to the data on the laptop (assuming that data was not backed-up), there is no way you can decrypt the hard drive unless the LUKS password is known.
Key escrow is one method of implementing centralized control over LUKS based encryption of laptops (especially in a corporate based environment). Let's take a look at the steps it requires.
Installation and Partitioning process:
During installation of the laptop, which is often done using a standard common kickstart file in a corporate environment, use the following directives in the partition option:
-
--backuppassword
: This will add a randomly-generated password to each encrypted volume. Each kickstarted laptop will have its own unique password. This password is created independently from the password which the user will use to decrypt his laptop. -
--escrowcert
: The random password created above is encrypted using a X.509 certificate and the encrypted file is stored in the/root
directory.
Before the installation process a certificate/private key pair is generated by the IT department to be used only for handling disk decryptions. The X.509 certificate is available during laptop kickstarts via an internally accessible URL. During partitioning, a per laptop, random, backup password is created, which is then immediately encrypted by using the certificate and stored in /root of the laptop. For example the partition part of the install looks something like this:
clearpart --all --initlabel part /boot --fstype=ext4 --asprimary --size=200 part pv.hd --grow --size=500 --encrypted --passphrase=”firsttime” --escrowcert http://someurl.corp.com/host.crt --backuppassphrase
The volume_key package is responsible for extracting the password from the LUKS header and encrypting it with the X.509 certificate provided.
Key escrow:
The --escrowcert
and --backuppassphrase
options used in the kickstart file creates two separate files. XXX-escrow
and XXX-escrow-backup-passphrase
, where XXX is the UUID of the partition which is encrypted. While the first contains data encryption, the second one contains the backup password.
Additional information like username, data/time stamp etc can be added to the filename. During post-install this escrow file is then uploaded to some management server or maybe some upload server (like ftp etc) where these files can be securely stored. These files are still encrypted with the certificate which was earlier created and as long as the private key is secure, brute force would be needed to decrypt these files.
Retrieval and password reset:
In the event that the user forgets his LUKS password or IT needs access to data on the laptop:
-
The relevant escrow file is located on the management server by using the earlier stored metadata like username, UUID of the partition, date/time stamp, etc.
-
The administrator then decrypts this escrow file, using the private key which may be in a local NSS database (more information about initial setup available here) on the server using something like:
volume_key --secrets [-d /path/to/nss/db] ./UUID-escrow-backup-passphrase
This will prompt for the private key password and print the backup password on the screen. The administrator then uses this to decrypt the user laptop.
-
Once the decryption is done, it may be important to reset the backup password to maintain access to the laptop, this can be done via:
volume_key --save [-c /path/to/cert] /path/to/volume --create-random-password escrow-packet-out
/path/to/volume
is a LUKS device, not the plaintext device contained within: (blkid -s TYPE /path/to/volume
) should report TYPE="crypto_LUKS"
.
This new packet can again be copied to the escrow server and used in future scenarios when password is forgotten again, etc.
Apart from the above several other scenarios exists which can be used for centralising storage and backup of escrow password.
However there are some caveats which one needs to understand:
-
While hard disk encryption adds to the security of the laptop or server used, it is most effective when the machine is shut down. This is mainly because data contents in the memory is not encrypted and can be retrieved via attacks like the cold boot attack.
-
Backup passwords in the LUKS header can be reset or completely removed if the user has access to write directly to the drive (usually via root access). Thus these methods can only be effective if corporate policy prevents users from having privileged access.
Overall full hard disk encryption via LUKS and password management via volume_key
should provide an effective solution for the management of passwords on encrypted laptops
저자 소개
Huzaifa Sidhpurwala is a Principal Product Security Engineer with Red Hat and part of a number of upstream security groups such as Mozilla, LibreOffice, Python, PHP and others. He speaks about security issues at open source conferences, and has been a Fedora contributor for more than 10 years.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.