SW Update를 안전하게! : TUF(The Update Framework)

Overview

현재 IT세상에서는 문자 그대로 수천개의 소프트웨어 업데이트 시스템이 사용되고 있습니다.

정적인 소프트웨어는 드물며, 심지어 일부 저장소는 몇 분마다 소프트웨어 또는 프로젝트 메타데이터에 대한 업데이트를 받습니다.
이와 같이 증가하는 업데이트들은 이를 관리하는 시스템에 대한 보안대책의 필요성을 강조시켰고, 지난 10년간 업데이트 파일의 신뢰성을 향상시키기위해 많은 방법이 생겨났지만 대부분은 저장소를 고려하지 않은 방법이었습니다.

TUF는 malware나 키 노출(Key Compromise)등 기타 공격에 대해 system resilience를 가지도록 설계되었습니다.

설계의 주된 목표는 다음과 같습니다 :

• 현재 존재하고 앞으로 생겨날 업데이트 시스템의 보안에 대한 framework 제공(라이브러리, 파일포맷, 유틸리티 등)
• 키 노출을 최소화시킬 방법을 제공
• 다양한 업데이트 시스템에 대한 유연성
• 기존의 업데이트 시스템에 대한 쉬운 통합(easy to integrate)

지금부터는 TUF가 어떠한 방법으로 보안성을 유지하는지 살펴보도록 하겠습니다.

이 문서는 The Update Framework를 한글화하고 조금 더 이해가 쉽게 조미료를 친 문서입니다.

Security

보통 소프트웨어 업데이트 시스템이 “Secure“하다라고 느껴질 때는 다음과 같습니다.

• 사용할 수 있는 최신 업데이트를 적절한 때에 알고있음
• 다운로드받는 모든 파일은 정확한 파일
• 파일을 확인하거나 다운로드를 받는것만으로는 안좋은 결과가 발생하지 않는다.

이를 실현하기위해서는 다양한 공격에 대한 예방 전략이 필요합니다.

Attacks and Weaknesses

지금부터는 소프트웨어 업데이트 시스템에 가해질 수 있는 몇 가지 공격들에 대해 알아보겠습니다.

• Arbitrary software installation
  
  다운로드 요청에 대해 공격자는 임의의 파일을 제공하고 클라이언트 시스템에서는 아무 의심없이 모든 파일을 설치함

• Rollback attacks
  
  공격자는 소프트웨어 업데이트 시스템에 클라이언트가 요구한 파일보다 오래된 파일을 요구, 파일 버전에 대해 알 방법이 없는 상태에서 클라이언트는 의심없이 파일을 설치하게 되고 해당 버전의 취약점은 공격자에 의해 이용될 수 있음.

• Fast-forward attacks
  
  업데이트시키려는 파일의 메타데이터속 파일 버전 정보를 임의로 증가시킴으로써 이후의 업데이트를 강제로 막음.

• Indefinite freeze attacks
  
  공격자가 소프트웨어 업데이트 시스템에게 업데이트하려고하는 버전에 대한 파일을 보여줌. 결과적으로 사용자는 새로운 파일(업데이트하기 위한)을 발견하지 못함.

• Endless data attacks
  
  공격자가 클라이어트의 업데이트 요청에 대해 끝없는 데이터 스트림을 반환함.
  이는 클라이언트들의 패키지 업데이트를 저해하고 네트워크 대역폭이나 CPU, 디스크 공간을 많이 소비하게 되어 클라이언트 시스템에 심각한 문제를 초래할 수 있음.

• Slow retrieval attacks
  
  공격자가 클라이언트의 업데이트 요청에 대해 매우 느린 스트림을 반환하여 업데이트를 완료하지 못하게 함.

• Extraneous dependencies attacks
  
  공격자는 클라이언트 시스템에 원하는 업데이트를 진행하려면 관련없는 소프트웨어를 같이 설치해야한다고 말함.
  추가적인 소프트웨어는 신뢰할 수 있는 소스에서 가져온 것일수도 있지만 악용할 수 있는 취약점을 가지고 있을 수도 있음.

• Mix-and-match attacks
  
  공격자는 현재 저장소에 존재하지 않는 패키지나 패키지의 메타데이터를 혼합하여 클라이언트에 보여줌.

• Wrong software installation
  
  공격자는 클라이언트에게 신뢰할 수 있는 파일을 주지만, 이것은 클라이언트가 원하는 파일이 아님.

• Replay attacks (Playback)
  
  클라이언트가 보내는 해시된 인증요청메세지를 공격자가 탈취하여 그대로 재인증 요청을 보냄. 해시된 메세지를 공격자가 복호화할수는 없지만 클라이언트의 정보가 담긴 메세지는 변형되지 않았으므로 접근을 허용함.

Security Design Principles

위와 같은 공격에 대해 시스템을 안전하게 보호하기 위해 TUF가 가지고 있는 기본 개념에 대해 알아보겠습니다.

Trust

다운로드 한 파일을 신뢰한다는 것은 그 파일이 악의적인 설계가 없는 그룹에서 제공되었다고 가정하는 것을 의미합니다. 소프트웨어 업데이트 시스템에서 자주 간과되는 두가지 측면은 다음과 같습니다.

• Trust는 영원히 부여되어서는 안됨. 갱신되지 않으면 소멸되어야 한다.
• Trust는 균등하게 부여되서는 안됨. 이로 하여금 Trust를 가지고 있는 root역할이 제공하는 file만을 신뢰할 수 있게 된다.

Mitigating Key Risk (Compromise-Resilience)

암호화 서명은 secure한 소프트웨어 업데이트 시스템에서 필수적인 요소입니다. 서명을 작성하는데 사용되는 키의 보안은 클라이언트의 보안에 직접적으로 영향을 끼치게 됩니다.
그래서 개인 키가 노출되지 않았다고 가정하는것보다, 키가 노출되었을 때 클라이언트를 가능한 한 안전하게 유지시키는 방법을 고려해야 합니다. 이것이 Resiliency를 위한 기본 원칙입니다.

• 빠르고 안전하게 키 교체 및 폐기
• 위험도가 높은 키에 대한 신뢰를 최소화 (온라인으로 유지되거나 자동화된 방식으로 사용되는 키가 노출될 경우 클라이언트에 즉각적인 위험을 초래해서는 안됨.)
• 여러 키 사용 및 서명의 임계값/정족수(threshold/quorum)

quorum : 의사결정하는데 필요한 최소한도의 인원수.

Integrity

TUF에서 Integrity를 보장한다는 것은 단일 파일에만 적용되는 것이 아니라 전체 저장소에 적용된다는 것을 의미합니다.
클라이언트 시스템에서 개별적으로 다운로드한 단일파일이 맞는지 확인하는 것도 중요하지만 그들이 다운로드했던 장소인 저장소가 무결한지 확인하는 것도 중요합니다.
예를 들어, 신뢰할 수 있는 그룹에서 제공한 두 파일을 받을 경우 소프트웨어 업데이트 시스템은 두 파일 모두의 최신 버전을 확인하여야 합니다.

Freshness

보안에 관련된 bug fix 업데이트가 잦기 때문에 소프트웨어 업데이트 시스템은 파일의 최신 버전을 얻는 것이 중요합니다.
그렇지 않으면 공격자가 클라이언트 시스템을 속여 오래된 버전의 소프트웨어를 설치하거나, 업데이트를 사용할 수 없다고 할 수도 있습니다.

Freshness를 보장한다는 것은 다음을 의미합니다.

• 이전에 본 파일보다 오래된 파일은 절대 허용 안함
• 업데이트를 가져오는데 문제가 있음을 인식

모든 상황에서 클라이언트가 성공적으로 업데이트를 진행할수 없을지도 모르지만(공격자가 존재할 경우), 반드시 원하던 업데이트가 모두 진행되지 않았음을 알 수 있어야 합니다.

+ Implementation Safety

메타데이터에 추가 정보를 포함하는 것을 지원합니다.

예를 들어 다운로드 될 대상 파일의 예상 크기를 알게되면 TUF는 파일을 다운로드 받을때 용량을 제한할 수 있게 됩니다. 결과적으로, TUF는 Endless data attacks로부터 안전하게 운영될 수 있습니다.

Roles and Metadata

TUF에서의 Role은 한 그룹이 행할수있는 일련의 행동을 정의해놓은것을 말합니다.
이는 TUF가 정확하게 지정된 그룹이 제공하는 정보만 신뢰할 수 있도록 할 수 있습니다.

Role은 저장소나 application의 상태에 대해 검증가능한 레코드를 생성하는데 사용되는 Metadata를 서명합니다.
이를 통해, 클라이언트는 어떤 파일을 업데이트할지 결정할 수 있습니다.

서로 다른 Metadata는 다른 정보를 가지고있고 또한 다른 Role에 의해 서명될것입니다.

서명된 Metadat에는 항상 만료 날짜가 포함되어 있습니다. 이를통해 오래된 Metadata를 감지할 수 있고, 클라이언트가 확인했던 Metadata보다 오래된 것을 수신하지 않을 수 있습니다.

꼭 필요한 최상위 Role은 4개가 있습니다 :

• Root
• Targets
• Snapshot
• Timestamp

또한 이에 상응하는 metadata file들도 존재합니다.

Root Metadata (root.json)

Signed by : Root Role

Root Role을 제외한 나머지 최상위 Role을 지정할 수 있습니다. 이러한 Role을 지정할 때, 서명하는데 필요한 최소한의 key수(Signature Threshold)와 함께 각 Role에 대해 신뢰할 수 있는 key들이 나열됩니다.

–> example of Root metadata

Targets Metadata (targets.json)

Signed by: Targets role

targets.json파일에는 클라이언트가 다운로드받고자하는 실제 파일의 정보가 포함되어있습니다. (대상 파일의 해시 및 크기)

–> example of Targets metadata.

Delegated Targets Metadata (role1.json)

Signed by: A delegated targets role

Target Metadata의 형식을 동일하게 따릅니다.

–> example of delegated Targets metadata.

Snapshot Metadata (snapshot.json)

Signed by: Snapshot role

Snapshot Metadata는 Timestamp Metadata를 제외한 모든 Metadata의 버전 정보를 나열합니다. 이 파일을 통해 클라이언트는 저장소에 존재하는 모든 파일의 일관된 보기를 보장할 수 있습니다.
즉, 옛날에 저장소에 존재했던 Metadata file (Target file)은 공격자에 의해 현재 Metadata와 합쳐지거나 또는 옛날것을 클라이언트에 보일 수 없게됩니다.

–>example of Snapshot metadata

Timestamp Metadata (timestamp.json)

Signed by: Timestamp role

Timestamp Metadata파일은 Snapshot Metadata의 해시와 크기를 나열합니다. 이 파일은 클라이언트가 업데이트를 검색할 때 첫번째로 다운로드받아야 될 유일한 파일입니다.
자주 재서명되고 유통기한이 짧기 때문에 클라이언트는 가장 최근 Metadata를 입수하는데 있어 방해를 받고 있는지 신속하게 탐지할 수 있습니다.

위의 Snapshot Metadata와 합쳐지지 않는 몇가지 이유가 있습니다.

1. Snapshot.json파일이 위임된 Role 수에 비례하여 증가한다는 점을 고려하면 Timestamp.json파일은 매우 자주 다운로드되기 때문에 가능한 작게 보관해야함.
2. Timestamp Role의 key는 온라인키이므로 위험성이 높으므로 오프라인으로 유지되어야하는 Snapshot파일은 별도의 key로 서명해야함.

–>example of Timestamp metadata