Operating Systems : Three Easy Pieces를 보고 번역 및 정리한 내용들입니다.

6. Cryptography And Operating Systems

이제는 이 암호화를 OS를 보호하는 데 어떻게 사용할 수 있을지에 대해 알아보자. 보안에 대해 다룬 첫 번째 장에서, OS가 컴퓨터의 모든 자원에 대한 제어 및 접근 권한을 가진다고 했던 것을 떠올려보자. 이는 컴퓨터 내에 암호화된 정보가 있고, 같은 컴퓨터에 이를 복호화하기 위한 키도 있다면, 그 컴퓨터의 OS는 우리가 원하든, 원치 않든 그 데이터를 복호화할 수 있음을 함축한다.

믿을 수 없는 OS를 사용한다고 해보자. 이 OS는 비밀 키에 접근해 이를 복사해놓고 원할 때마다 재사용할 수 있다. 반대로 믿을 수 있는 OS의 경우는 어떨까? 믿을 수 있는 OS를 사용하는데 OS에게 데이터를 숨길 필요가 있을까? 이 경우에는 암호화를 사용할 필요가 없다.

OS가 지금은 믿을 수 있지만 나중이 걱정된다면, 데이터를 암호화해 저장하고 키는 다른 곳에 저장하는 방법을 사용할 수 있다. 물론 이 경우에도 현재 OS 보안에 대한 판단이 잘못된 것이었다면 암호화를 통한 보호는 효력을 잃겠지만 말이다.

OS에서 일어날 수 있는 보안 침해가 모두 영구적인 것은 아니라는 주장도 있을 수 있다. 보안 침해에는 다양한 것들이 있지만, 그 중 어떤 것은 공격자에게 일부 특정 자원들에 대한, 일시적인 접근만을 허용하는 것일 수 있다. 이런 경우, 암호화된 데이터가 평문으로 저장되지 않고 복호화 키도 공격자가 공격하는 그 시점, 혹은 그 장소에서 접근할 수 없는 것이라면, 데이터 암호화는 여전히 유효하다. 문제는 공격자의 성공적인 공격이 언제, 어디서 일어날지를 사전에 알 수 없다는 것이다. 따라서 이 방식을 취한다면, 모든 비밀 노출을 최소화해야만 한다. 노출을 최소화할 방법에는 복호화 빈도를 줄이고, 평문 데이터도 빠르고 조심스럽게 처리하고, 암호화 연산을 수행할 때를 제외하고는 키의 평문 버전을 시스템에 두지 않는 방법 등이 있지만, 이러한 최소화는 달성하기 어렵다.

만약 암호화가 믿을 수 없는 OS에 대한 완벽한 보호를 제공해줄 수 없다면, 대체 OS에서 암호화는 어디에 쓸 수 있는걸까? 이전 인증 장에서 그 사례가 나타난다. 어떤 암호 작업은 일방향적으로, 암호화는 할 수 있지만 복호화는 불가능하다. 우리는 이를 패스워드를 암호화된 형식으로 저장하는 데 쓸 수 있다. 이렇게 저장된 패스워드는 OS에 보안 침해가 일어나 탈취되더라도 복호화할 수 없기에 안전하다.

또한 암호화는 분산 환경에서 한 컴퓨터에서 데이터를 암호화하고 네트워크를 통해 전송할 때도 유용하다. 네트워크를 이루는 구성 요소들은 우리가 가진 컴퓨터의 부분이 아니며, 따라서 키에도 접근할 수 없다. 따라서 데이터는 전송 중에 보호될 수 있다. 물론 최종 목적지에 있는 기기는 이 데이터를 사용하기 위해 키를 필요로 하지만, 이와 관련한 이슈는 다음 장에서 다루게 될 것이다.

또 다른 것에는 무엇이 있을까? OS를 통하지 않고 하드웨어에 접근할 수 있다면 어떨까? 만약 데이터가 하드웨어에 암호화되어 저장되고 키는 하드웨어에 없다면, 암호화를 통해 데이터를 보호할 수 있을 것이다. 이러한 방식의 암호화를 서로 다른 두 기기 사이의 전송 데이터 암호화(in-transit data encryption)과 구분해, 저장 데이터 암호화(at-rest data encryption)라 부른다. 이에 대해 더 자세히 알아보자.

7. At-Rest Data Encryption

영구 저장과 관련된 장들에서 보았듯, 데이터는 디스크 드라이브 등의 여러 매체에 저장될 수 있다. 만약 이 데이터가 민감한 데이터라면, 우리는 이 데이터가 비밀성, 무결성 등의 보안 속성도 가지고 있기를 원할 것이다. 이러한 목표를 달성하기 위한 한 테크닉은 데이터를 평문이 아닌, 암호화된 형식으로 저장하는 것이다. 다만 암호화된 데이터는 대부분의 계산에서 직접 사용될 수 없기에, 저장된 데이터를 사용하려면 복호화가 필수적이다. 물론 데이터를 사용하지 않고 그 안전한 복사본을 저장하기만 하면 된다면 복호화는 불필요해지겠지만, 그런 경우가 흔하지는 않다.

이 데이터는 여러 방식으로 암호화될 수 있으며, 그 중 흔히 쓰이는 것 중 하나로는 전체 디스크 암호화(full disk encryption)가 있다. 이는 보통 저장 장치의 (거의) 모든 컨텐츠들을 암호화하는 것을 의미한다. 전체 디스크 암호화는 보통 하드웨어나 시스템 소프트웨어를 통해 제공되는데, 두 경우 모두에서 OS는 중요한 역할을 한다.

일반적으로는 부팅을 할 때 사용자에게 복호화 키, 또는 복호화 키를 얻기 위해 쓸 수 있는 정보를 요청한다. 만약 올바른 정보가 제공되면 복호화를 수행하기 위해 필요한 키가 사용 가능해진다. 장치 내에 있는 데이터는 암호화되어있고, 이 데이터는 장치 밖으로 이동할 때 복호화 된다. 데이터는 공유 버퍼, 혹은 사용자 주소 공간 등, 컴퓨터 메모리에 저장되고 있을 때에는 복호화된 상태를 유지한다. 새 데이터가 장치로 보내질 때에는 우선 암호화되며, 절대 복호화된 상태로는 저장 장치에 저장되지 않는다. 복호화 키를 얻기 위한 최초의 요청 이후, 암호화와 복호화는 사용자와 애플리케이션에게는 완전히 투명하게 나타난다. 즉 사용자와 애플리케이션는 암호화와 복호화가 일어나고 있다는 사실을 모른 채, 평문 데이터만을 이용할 수 있게 된다. 컴퓨터가 재부팅될 때까지 사용자와 애플리케이션은 데이터를 암호화된 형식으로 보지 않으며, 키에 대한 요청도 다시 받지 않는다.

암호화는 계산 비용이 많이 드는 작업이며, 특히 소프트웨어에서 수행될 때에는 더 그렇다. 그렇기 때문에 소프트웨어 기반의 전체 디스크 암호화를 수행할 때에는 오버헤드가 발생한다. 이 오버헤드의 양은 수행되는 작업에 따라 달라지는데, 디스크를 많이 쓰는 작업의 경우 흔히 수 퍼센트의 추가적인 지연이 발생하고, 디스크를 적게 쓰는 작업들의 경우에는 거의 인지할 수 없을 정도다. 하드웨어 기반의 전체 디스크 암호화의 경우, 디스크 드라이브의 정격 속도에 가까운 속도를 얻을 수 있어, 전체 디스크 암호화를 사용하지 않는 경우와 거의 속도 차이가 나지 않는다.

이 암호화를 사용했을 때 보호할 수 있는 것에는 어떤 것이 있을까? 우선은 이 암호화가 제공할 수 없는 것들에 대해 먼저 알아보자.

• 이 암호화를 사용한다고 해서, 사용자의 데이터 접근 권한에 따른 보호가 제공되는 것은 아니다.
• 데이터를 노출시키는 애플리케이션 결함을 보호하지 못한다. 이러한 결함은 공격자가 사용자인 체 할 수 있게 하므로, 사용자가 암호화되지 않은 데이터에 접근할 수 있다면 공격자도 그렇다.
• 시스템 관리자와 같은, 권한을 가지고 있는 믿을 수 없는 사용자에 대한 보호를 제공하지 못한다.
• OS 자체가 가지고 있는 보안 결함에 대한 보호도 제공하지 못한다. 키가 제공되면 OS는 믿을 수 있든, 안전하든, 침해가 일어났든, 안전하지 않든 상관 없이 이 키를 사용할 수 있게 된다.

그렇다면 이 암호화를 통해 얻을 수 있는 이익에는 뭐가 있을까? 데이터가 저장된 하드웨어 장치가 물리적으로 한 기계에서 다른 곳으로 옮겨졌을 때, 해당 기계의 OS는 그 장치에 저장된 접근 제어 정보를 따를 필요가 없다. 사실 이 OS는 그 장치에 접근하기 위해 같은 파일 시스템을 쓸 필요조차 없다. 이 OS는 장치를 조직화된 파일 시스템이 아닌, 그저 데이터 블럭의 소스 정도로 다룰 수 있고, 해당 장치의 파일과 연관된 접근 제어 정보들은 무시될 수 있다.

하지만 장치 내 데이터가 전체 디스크 암호화로 암호화되어 있는 경우, 보통 새 기계는 그 암호화 키를 얻을 수 없다. 물론 데이터 블럭에 접근해 그 값을 읽을 수는 있겠지만, 이 정보들은 암호화되어 있고 키가 없이는 복호화될 수 없다. 예를 들어 하드웨어 도난이 일어나 다른 기계로 옮겨지는 경우, 특히 도난이 잦은 모바일 장치들의 경우, 이 이점은 유용하게 쓰일 수 있다.

다른 형태의 저장 데이터 암호화의 경우, 즉 전체 데이터 중 암호화할 일부를 선택해야 하는 경우, 시스템은 얼마나 많은 데이터를 암호화 할지, 어떻게 키를 얻을지, 언제 데이터를 암호화하고 복호화할지 등의 이슈들을 다뤄야 한다. 이 물음들에 대한 답에 따라 그 결과로 얻어지는 보호의 종류 또한 달라지게 된다. 이 경우 소프트웨어는 일반적으로 캐시를 포함한 어떠한 데이터도 암호화되지 않은 상태로 저장하지 않아야 하고, 암호화 키는 불법적으로 데이터에 접근하려 시도하는 그 누구에게도 사용가능하지 않아야 한다. 이러한 보호가 유효한 환경은 상대적으로 적지만, 몇 가지 흔히 볼 수 있는 사례들도 있다.

• 사용은 되지 않지만, 복사되고 저장되어야 하는 데이터의 경우. 이 경우, 데이터는 생성과 동시에 암호화될 수 있고, 복호화되지 않거나, 아주 특별한 환경에서, 데이터 소유자의 제어 아래에서만 복호화된다.
• 민감한 데이터를 클라우드에 저장하는 경우. 만약 클라우드 제공자를 완전히 믿을 수 없다면, 클라우드에 데이터를 저장하기 전에 암호화를 하는 것은 현명한 선택이다. 많은 클라우드 백업 제품들이 이러한 기능을 제공한다. 이 경우 암호화와 키 사용은 데이터를 신뢰할 수 없는 시스템으로 옮기기 전, 혹은 해당 시스템으로부터 암호화된 데이터를 가져오고 난 후에 일어난다.
• 애플리케이션에서 수행되는 사용자-레벨의 암호화. 이 경우 암호화는 애플리케이션이 수행하며, 사용자는 애플리케이션이 암호화 키를 사용할 수 있도록 하는 작업을 해야 한다. 애플리케이션은 이상적으로는 암호화되지 않은 데이터와 암호화를 위해 쓰인 키가 암호화 이후에는 사용될 수 없음을 보장할 수 있어야 한다.

선택된 저장 데이터 암호화의 한 가지 중요한 특이 케이스로는 패스워드 볼트(password vault)가 있다. 사용자들은 보통 패스워드를 필요로하는 여러 원격 사이트와 상호작용한다. 각 사이트마다 서로 다른 패스워드를 사용한다면 가장 좋겠지만, 그렇게 많은 패스워드들을 모두 기억하는 것은 힘들다. 이를 해결하기 위해서는 모든 패스워드들을 암호화하고 컴퓨터에 저장한 후, 그 패스워드들이 쓰이는 사이트로 인덱싱하는 것이다. 만약 어떤 패스워드가 필요하게 되면, 이 패스워드는 복호화되고 해당 사이트에 제공된다.

패스워드 볼트 및 그와 비슷한 경우, 시스템은 데이터 암복호화를 위해 필요한 키를 획득할 방법을 가지고 있어야 한다. 만약 공격자가 키를 획득할 수 있게 되면 암호화가 쓸모 없어지므로, 키를 안전하게 저장하는 것이 중요하다. 이 키가 암호화되지 않은 상태로 컴퓨터의 어딘가에 저장되면 암호화된 데이터는 언제든 복호화될 수 있으므로, 잘 서계된 암호화 시스템에서는 그렇게 하지 않는다.

키는 필요할 때 사용자에게 물어보거나, 혹은 키를 얻을 수 있는 패스프레이즈를 물어봄으로써 얻고, 이후 필요한 패스워드를 복호화하는 데 쓰인다. 가장 보안적으로 안전한 방법은 복호화가 수행되고 나서 최대한 빨리 사용된 키를 없애는 것이지만, 이 경우 사용자는 패스워드가 필요할 때마다 키를 재입력해야 한다. 따라서 대부분의 경우 키를 일정 시간 RAM에 저장하는 방식으로 타협한다. 사용자가 로그아웃하거나 시스템이 종료되거나, 패스워드 볼트를 다루는 애플리케이션이 종료되는 경우 키는 잊힌다.

이는 사용자가 처음 접근할 때만 패스워드를 물어보고, 로그아웃하기 전까지는 재인증을 필요로하지 않는 시스템과 비슷하며, 그런 시스템과 같은 단점도 공유한다(권한이 없는 사람이 타인의 접근 권한을 사용할 수 있게 되는 것).

8. Cryptographic Capabilities

이전 접근 제어 장에서 이야기했던 자격(capability)의 문제점을 다시 생각해보자. 사용자 프로세스는 어떤 비트 패턴이든 만들 수 있고, 존재하는 비트 패턴을 복사해 다른 프로세스에게도 줄 수 있다. 자격의 경우도 마찬가지로, 사용자는 자격을 위조해 자신이 원하는 자원에 접근할 권한을 스스로에게 부여할 수 있었다.

암호화는 위조 불가능한 자격을 만드는 데에 쓰일 수 있다. 신뢰할 수 엔티티는 암호화를 이용해, 소유자가 특정 자원에 접근할 권한을 가지고 있음을 표시하는, 충분히 길고 보안적으로 안전하게 암호화된 자료 구조를 만들 수 있다. 이 자료 구조는 사용자에게 주어지고, 사용자는 그에 해당하는 자원의 소유자에게 이 자료 구조를 보여 접근 권한을 얻는다. 자원을 실제로 제어하는 시스템은 접근 권한을 주기 전에 이 자료 구조의 유효성을 체크할 수 있어야 한다.

이런 암호화 자격은 대칭 키 방식으로도 만들 수 있고, 공개 키 방식으로도 만들 수 있다. 대칭 키 암호화를 사용하면, 자격 생성자와 이를 확인하는 시스템이 모두 같은 키를 공유해야 한다. 이 방식은 두 엔티티가 같은 시스템인 경우에 더 적합하다. 어떤 이는 단일 기기 내에서 왜 굳이 암호화 자격을 사용해야 하는지 궁금해할 수도 있지만, 거기에는 몇 가지 이유가 있다. 예를 들어 자원을 제어하는 기기가 많은 수의 사용자를 가지는 경우, 특히 오류와 지연에 대해 신경을 써야 하는 분산 환경의 경우, 각 사용자들에 대한 접근 상태를 추적하는 것은 비싸고 복잡하다. 혹은 시스템이 접근 권한에 대한 이전권을 제공하고자 하는 경우, 예를 들어 보안 주체가 이 기기에서 저 기기로 이동하곤 하는 경우, 자격 또한 주체와 함께 이동할 수 있도록 해, 어디에서든 사용할 수 있도록 하는 것이 더 그럴듯하다. 대칭 키 암호화 자격은 자격을 만들고 검증하는 모든 기계들이 서로 신뢰할 수 있고, 키 분배도 그렇게 문제가 되지 않는 경우에 적합하다.

자격 생성을 위해 공개 키 암호화를 사용하는 경우, 자격 생성자와 자원 제어자는 같은 곳에 위치할 필요가 없고, 둘 사이의 신뢰 관계 또한 그리 강하지 않아도 된다. 자격 생성자는 키 쌍 중 하나를 가지고, 자원 제어자는 나머지 하나를 가진다. 자격에 들어 있는 내용이 비밀이 아니라면, 공개 키는 말 그대로 모두에게 공개되어도 상관이 없다. 반대로 어느 정도의 비밀성이 필요하다면, 자격이 필요한 일부 엔티티들에게만 공개 키를 분배해서 사용하면 된다.

자원 관리자(resource manager)는 자격 증명(어떤 주체가 어떤 자원을, 어떻게, 얼마 동안 쓸 수 있는지를 표시)을 만들어 개인 키로 암호화하며, 이것을 검증하고자 하는 사람은 관리자의 공개 키를 이용해 복호화한다. 자원 관리자만이 개인 키를 알고 있는 한, 다른 사람이 자격을 만들어 사용하는 경우는 일어나지 않는다.

암호화 자격에는 많은 양의 정보들이 들어갈 수 있다. 강한 암호화는 이 정보들의 무결성을 보장하므로, 자격은 이 정보들을 이용할 수 있다. 이 특징은 자격 생성자가 적어도 어느 정도, 임의로 자격을 복제하고 공유하는 것을 방지할 수 있다. 예를 들어 네트워크 컨텍스트에서 사용되는 암호화 자격에 특정 IP 주소 정보를 추가한다고 해보자. 이 자격은 오직 메시지가 해당 주소에서 온 것일 때에만 유효한 것으로 생각될 수 있다.

다른 여러 암호화 기법들도 사용될 수 있다. 중요한 것은 암호화 자격은 충분히 길게 만들어, 브루트 포스 공격을 통해 유효한 자격을 찾는 일, 혹은 이 자격을 추론하는 일이 계산적으로 불가능하게 해야 한다는 것이다.