KR20110031426A

KR20110031426A - 소프트웨어 애플리케이션들의 화이트박스 구현들을 생성하는 시스템 및 방법

Info

Publication number: KR20110031426A
Application number: KR1020107028600A
Authority: KR
Inventors: 필립 알렌 아이젠; 그랜트 스튜어트 구디스; 다니엘 엘리 머독
Original assignee: 어데토 캐나다 코포레이션
Priority date: 2008-05-23
Filing date: 2009-05-25
Publication date: 2011-03-28
Also published as: EP2304552A1; JP5460699B2; JP2011521366A; US20110067012A1; CA2724793C; CA2724793A1; EP2304552B1; WO2009140774A1; US8510726B2; CN102047220A; CN102047220B; KR101597251B1; EP2304552A4

Abstract

화이트-박스 암호화를 사용하여 DRM-보호 파일들과 같은 파일들을 생성하는 개발 슈트. 상기 개발 슈트는 코드 생성 도구, 데이터 변환 엔진, 및 화이트-박스 생성 도구, 및 화이트-박스 라이브러리로 이루어져 있다. 상기 화이트-박스 암호화 콘텍스트에서, 상기 데이터 변환 엔진은 암호화 동작 및 주변 코드 간의 경계를 보호하는데 사용된다. 특히, 상기 데이터 변환 엔진은 암호화 동작들로의 입력들 및 상기 암호화 동작들로부터의 출력들에 대해 데이터 변환들을 적용하도록 사용된다. 사용자가 화이트-박스 매개변수화 파일을 통해 변환들이 요구됨을 지정할 경우에 상기 코드 생성 도구는 사용자에 의해 지정된 정보를 상기 데이터 변환 엔진이 파악하는 형태로, 다시 말하면 데이터 변수들 및 기능 프로토타입들에 관한 수식어들로서 적용한다. 상기 데이터 변환 엔진은 그후 상기 지정된 변환들을 적용하고, 변환들이 선택된 데이터 생성 도구로 정보를 전달한다.

Description

소프트웨어 애플리케이션들의 화이트박스 구현들을 생성하는 시스템 및 방법{System and method for generating whitebox implementations of software applications}

본 발명은 일반적으로 기술하면 암호화에 관한 것이다. 좀더 구체적으로 기술하면, 본 발명은 공격자(attacker)가 실행 소프트웨어에 완벽하게 접근하여 실행 소프트웨어를 통제하는 환경에서 안전하게 동작하도록 설계된 소프트웨어 애플리케이션들의 개발에 관한 것이다.

화이트-박스 암호화 소프트웨어는, 화이트-박스 공격 '콘텍스트(context)에서, 다시 말하면, 적어도 소프트웨어 애플리케이션의 부분들, 그리고 잠재적으로는 전체 구현이 상기 소프트웨어가 실행하고 있는 플랫폼의 통제력을 어느 정도 지니는 공격자, 및 아마도 상기 소프트웨어가 실행하고 있는 플랫폼의 통제력을 전부 지니는 공격자에게 잠재적으로 노출되는 환경에서, 암호화 기능들을 수행하는 소프트웨어이다.

그러한 콘텍스트는, 예를 들면 텔레비전 프로그램들, 영화들, 음악 등이 방송을 통한 기존의 텔레비전상에서나 또는 DVD 플레이어를 통해서 보다는 오히려 개인용 컴퓨터(PC) 또는 기타 유사한 물품의 전산 장치상에서 표시되는 디지털 저작권 관리(digital rights management;DRM)와 같은 암호화 애플리케이션과 관련하여 발생한다. 그러한 물품 장치들을 가지는 많은 소유자가 저작권법을 존중하고는 있지만, 다른 사람들은 매체 콘텐츠의 불법 복사본들을 제작 및 판매하여 자신들이 이용한 대가를 콘텐츠의 소유자들에게 지급하지 않고 콘텐츠를 도용함으로써 PC들 또는 유사한 장치들에 관련된 매체를 이용하려는 시도를 하게 된다. PC들은 특히 노출된 환경에 있는데, 그 이유는 전문적인 공격자(knowledgeable attacker)가 상기 장치를 완벽하게 통제할 수 있고 실행하는 소프트웨어를 세부적으로 지켜 볼 수 있으며 디버거(debugger)를 사용하여 상기 소프트웨어의 실행을 통제, 정지 또는 변경할 수 있고, 이용될 수 있는 동작의 패턴들 및 그와 유사한 것들을 찾아서 동일한 코드를 반복 실행할 수 있기 때문이다.

화이트-박스 암호화 소프트웨어는 그러한 콘텍스트에서 실행하도록 설계된 것이다. 화이트-박스 공격 콘텍스트의 타깃이 되는 암호화 기능은, 그것은 기존의 암호(cipher)를 잘 구현할 수 있지만, 상기 소프트웨어가 동작하는 방식을 공격자가 파악하지 못하게 하기 위해, 매우 독특한 방식으로 구현한다. 예를 들면, 전형적으로는, 부분적인 평가의 화이트-박스 암호화 소프트웨어의 잔류부분(remainder)에 키들이 엠베드(embed)되거나 상기 키들이 부호화된다. 더욱이, 암호의 입력 및 출력 텍스트들은, 화이트-박스 암호화 구현에 대한 공격을 개시하는데 기존의 암호 구현들의 공격자의 지식을 덜 유용하게 하도록 암호화되는 것이 전형적이다.

과거에는, 화이트-박스 라이브러리 도구들에 접근하는데 사용되는 API(Application Procedural Interface; 애플리케이션 절차 인터페이스) 호출들을 또한 포함하는 사용자 정의 소프트웨어 내에 병합되는 보안 매개변수들을 사용자가 결정하여 지정해야 할 필요가 있다. 다시 말하면, 과거에는 화이트-박스 암호화 동작들이, 소프트웨어 내에 구축된 화이트-박스 구현들을 포함시킨 다음에 선택적으로는 Cloakware Transcoder^TM와 같은 난독화(obfuscating) 및/또는 템퍼-프루핑(temper-proofing) 도구를 사용하여 상기 화이트-박스 구현들의 인터페이스 데이터(예컨대, 암호화를 위해, 이는 전형적으로 키 및 평문텍스트(plaintext) 입력들 및 암호텍스트(ciphertext) 출력을 포함함)를 보호함으로써 소프트웨어 애플리케이션들 내에 삽입되어 왔다. 암호화 기능을 이용하는 소프트웨어 및 이를 구현하는 소프트웨어, 키(또는 공개 키 암호화의 경우에, 키들), 텍스트 입력, 및 텍스트 출력을 함께 올바르게 연결하기 위한 책임은 암호화 기능을 사용하는 프로그래머(프로그래머/사용자)에게 있다.

매 단계마다 프로그래머/사용자에 의해 통제되기 때문에, 모든 문제는 인간의 완벽한 행위를 기대하는 것에 원인이 있다. 프로그래머/사용자가 이 문제들을 해결하면, 그 결과는 기능이 의도된 대로 이루어지는 것이다. 프로그래머/사용자가 한 단계라도 놓치거나 한 단계를 잘못 수행하는 경우에는, 포착하기 쉽거나 어려운 방식으로 의도된 것과는 달라질 수 있다. 후자의 경우가 훨씬 더 위험한데, 그 이유는 포착하기 쉬운 오류들이 대개 테스트시에 포착되고 포착하기 어려운 오류들이 자칫하면 놓치게 될 수 있기 때문이다.

그러므로, 화이트-박스 암호화 구현들의 도래로 DRM 콘텐츠 배포 시스템들이 성장할 수 있게 되었지만, 그럼에도 상기 구현의 소위 (암호화되지 않은 텍스트가 화이트-박스 구현에 들어가거나 화이트-박스 구현에 남아 있게 되는) 페리-크립틱(peri-cryptic) 태양 및 (암호화된 텍스트가 한 암호 형태로부터 다른 한 암호 형태로 이동하는) 인터-크립틱(inter-cryptic) 태양에 관련된 큰 문제가 남아 있음을 알 수가 있게 된다. 화이트-박스 암호들 또는 암호화 해시(cyptographic hash)들 자체와 아울러, 화이트-박스 암호들 또는 암호화 해시들이 상주하는 소프트웨어의 구성, 및 이전에 전문적인 사용자(knowledgeable user)에 의해 수작업으로 소프트웨어의 페리-크립틱 및 인터-크립틱 부분들이 세부적으로 구성되어야 했던 경우에, 암호화되거나 해시된 콘텐츠가 이동하는 정보 파이프들의 '플러밍(plumbing)'을 형성하는 다수의 암호화들 및 해시들을 시스템이 이용하게 하는 서로 다른 암호화 컴포넌트들 간의 연결들의 구성을 개선할 필요가 있다.

본 발명은 화이트-박스 암호화를 사용하여 보호 소프트웨어 애플리케이션을 생성하는 컴퓨터-구현 기법 및 컴퓨터 프로그램 생성물을 제공하는 것이다.

화이트-박스 암호화(white-box cryptography)를 사용하여 보호 소프트웨어 애플리케이션을 생성하는 컴퓨터-구현 방법, 및 상기 방법을 구현하는 컴퓨터 프로그램 생성물이 제공된다. 상기 방법은 애플리케이션 소스 코드 및 추상화(abstract)된 화이트-박스 기능 호출들을 포함하는 적어도 하나의 입력 소스 파일을 수신하는 단계; 및 각각의 추상화된 화이트-박스 기능 호출에 대해 암호화 도메인 매개변수들을 포함하는 매개변수화(parameterization) 파일을 수신하는 단계를 포함한다. 그리고 나서, 각각의 추상화된 화이트-박스 기능 호출의 암호화 도메인 매개변수들에 따라 각각의 추상화된 화이트-박스 기능 호출을 정의하는 화이트-박스 호출 정의 데이터가 생성된다. 그리고 나서, 블록 또는 비대칭 암호와 같은 적어도 하나의 데이터 변환이 상기 입력 소스 파일 및 상기 화이트-박스 호출 정의 데이터에 적용되어 변환된 소스 파일 및 변환된 화이트-박스 호출 정의 데이터가 각각 생성된다. 그리고 나서, 상기 화이트-박스 호출 정의 데이터 및 상기 변환된 화이트-박스 호출 정의 데이터에 따라 각각의 화이트-박스 기능 호출에 대해 인스턴스(instance)-특정 데이터를 포함하는 데이터 초기화들이 생성된다. 그리고 나서, 상기 변환된 소스 파일, 상기 변환된 화이트-박스 정의 데이터 및 데이터 초기화 코드는 컴파일되고, 결과적으로 컴파일된 코드는 화이트-박스 라이브러리에 링크되어 실행가능한 소프트웨어 애플리케이션이 제공된다. 상기 화이트-박스 호출 정의 데이터는, 상기 애플리케이션 소스 코드에 화이트-박스 구현 '애플리케이션 절차 인터페이스(Application Procedural Interface; API)들을 자동으로 연결시켜 주는 코드, 및 통신해야 할 때 한 화이트-박스 구현 API를 다른 한 화이트-박스 구현 API를 연결시켜 주는 코드를 생성한다.

이러한 태양의 실시예들에 의하면, 상기 화이트-박스 호출 정의 데이터는 각각의 화이트-박스 기능 호출에 대해 선택되는 매개변수들을 지정하는 화이트-박스 메타데이터 및 화이트-박스 호출 정의 파일을 포함할 수 있고, 상기 변환된 화이트-박스 호출 정의 데이터에 대한 상기 적어도 하나의 데이터 변환의 적용은 선택 매개변수들에 대해 선택되는 데이터 변환들을 지정하는 변환 메타데이터 및 변환된 화이트-박스 호출 정의 파일을 생성한다. 상기 데이터 초기화들을 생성하는 것은 상기 화이트-박스 메타데이터 및 상기 변환 메타데이터에 따라 데이터 초기화 파일을 생성하는 것을 포함할 수 있다.

본 발명의 다른 태양들 및 특징들은 이하 첨부도면들과 연관지어 본 발명의 특정 실시예들을 기술하는 내용을 검토해 보면 당업자에게 자명해질 것이다.

지금부터 첨부된 도면들을 참조하여 단지 예로써만 본 발명의 실시예들을 기술하면 다음과 같다.

본 발명은 화이트-박스 암호화를 사용하여 보호 소프트웨어 애플리케이션을 생성하는 컴퓨터-구현 기법, 및 상기 기법을 구현하는 컴퓨터 프로그램 생성물을 통해, 화이트-박스 암호들 또는 암호화 해시들 자체와 아울러, 화이트-박스 암호들 또는 암호화 해시들이 상주하는 소프트웨어의 구성, 및 이전에 전문적인 사용자에 의해 수작업으로 소프트웨어의 페리-크립틱 및 인터-크립틱 부분들이 세부적으로 구성되어야 했던 경우에, 암호화되거나 해시된 콘텐츠가 이동하는 정보 파이프들의 '플러밍'을 형성하는 다수의 암호화들 및 해시들을 시스템이 이용하게 하는 서로 다른 암호화 컴포넌트들 간의 연결들의 구성을 개선한다.

도 1은 본 발명의 한 실시예에 따른 화이트-박스 암호화 통합을 위한 기본적인 설계 흐름도이다.
도 2는 본 발명의 한 실시예에 따른 화이트-박스 암호화에 대해 확장된 설계 흐름도이다.
도 3은 본 발명의 한 실시예에 따른 연쇄(chaining)된 암호화 시나리오의 도면이다.
도 4는 연쇄된 암호화 API가 본 발명의 한 실시예에 따라 이용되는 연쇄된 암호화 시나리오의 도면이다.
도 5는 본 발명의 한 실시예 및 그의 동작을 예시한 개략도이다.
도 6은 본 발명의 한 실시예에 따른 견고한 구현을 빌드(build; 구축)하기 위한 단계들을 예시한 도면이다.

화이트-박스 암호화 기능을 이용하는 애플리케이션들의 페리-크립틱(peri-cryptic) 및 인터-크립틱(inter-cryptic) 부분들을 구성하는 시스템들을 구축하는 현재의 오류 유발 방법들이 훨씬 더 신뢰성있게 자동화된 방법들로 대체될 수 있게 하기 위해, 화이트-박스 암호화 기능을 이용하는 애플리케이션들의 페리-크립틱 및 인터-크립틱 부분들을 구성하는 단계들이 자동화될 수 있게 하는 방법 및 시스템에 대한 필요가 있음을 알 수가 있게 된다. 이를 달성하기 위해, 애플리케이션들의 일반적인 인트라-크립틱(intra-cryptic) 부분들(실제로 화이트-박스 동작들을 수행하는 부분들)이 위에 언급된 자동화된 시스템에 적합하도록 기존에 이루어졌던 것보다 더 융통성있게 하는 실시예들이 개시되어 있다.

그러한 시스템의 이점들은 수작업에 의한 어셈블리 코드를 작성하는 대신에 코드를 컴파일함으로써 획득되는 이점과 유사하다. 이론적으로는, 유능한 프로그래머들이 수작업에 의한 어셈블리 코드로 애플리케이션을 작성할 수 있을 것이다. 그러나, 실제로는, 수작업에 의한 어셈블리 코드는 오류가 대단히 유발되며, 컴파일러들은, 저-수준의 매우 세부적인 소프트웨어 구성 체제를 훨씬 더 자동화된 것으로 대체함으로써, 어셈블리-코드 레벨로는 결코 달성될 수 없을 정도로 소프트웨어 시스템들을 복잡하게 할 수 있다.

본 발명의 한 태양은 화이트-박스 구현들의 페리-크립틱 및 인터-크립틱 태양들이 추상화 및 자동화될 수 있게 하는 시스템 및 방법을 제공하여, 이전에 수작업으로 부호화된 페리-크립틱 및 인터-크립틱 소프트웨어에 의해 달성하기에 어렵거나 실행가능하지 않던 복잡성 수준에 있는 화이트-박스 암호화 구현들의 사용들을 사용자들이 구현할 수 있게 하면서, 또한 마치 수작업에 의한 어셈블리 코드를 C++와 같은, 고-수준의 언어의 소스 코드로부터 컴파일된 코드로 대체함으로써 훨씬 간단한 프로그램들이 유리한 것처럼, 프로그래머/사용자가 화이트-박스 암호화 구현들을 생성하기에 훨씬 편리하게 함으로써 사용자들이 화이트-박스 암호화를 훨씬 간편하게 사용하기에 유리하게 할 수 있게 하는 것이다.

이러한 자동화 태양은 다른 암호화 기능 형태들이 표현되는 방식들의 단일화(unification)이다. 예를 들면, C++와 같은 컴파일 언어에서, 동일한 구문 형태는, 그 구문 형태가 2개의 정수이든, 2개의 부동 소수점 숫자이든 또는 추가되는 2개의 복소수이든 가산을 위해 사용된다. 각각의 콘텍스트에 대해 적합하게 구현되는 개념으로서의 언어 및 그의 컴파일러 추상화 가산은, 상기 구현이 (상기 언어가 정수들 및 부동 소수점 숫자들에 대한 것일 때) 상기 컴파일러에 내장되든 또는 상기 구현이 (상기 언어가 복소수들에 대한 것일 때) 표준 라이브러리의 일부이든 관계없이, 사용된다. 화이트-박스 암호화 동작들에 대해 유사한 단일화가 본원 명세서에 개시된다. 각각의 암호화 동작이 그 자체의 고유한 인터페이스를 지니고 그 자체의 고유한 표현 방식을 요구할 경우에는, 자동화될 가능성이 거의 없다. 그 이유는 적합한 선택들을 하는 책임들 대부분이 반드시 프로그래머/사용자에게 있어야 하기 때문이다. 상기 인터페이스들 및 표현 방식들이 단일화될 경우에는, 상기 시스템이 특정 암호들에서부터 추상화하여 자동화된 방식으로 각각의 콘텍스트의 요구들에 대처할 수 있다.

따라서, 화이트-박스 라이브러리 도구들에 액세스하는데 사용되는 API 호출들을 포함하는 사용자 정의 소프트웨어로부터 보안 관련 매개변수들을 분리시키는 실시예들이 개시된다. 이는 사용자 정의 소프트웨어에 대한 변경들을 필요로 하지 않고 단순히 상기 매개변수들을 변경함으로써 애플리케이션에 적용되는 보호의 타입 및 보안 수준을 용이하게 변경할 수 있게 해 준다. 이는, 보안 구현들, 및 코드들이 변경될 수 있게 하거나 추가적인 도구들 및/또는 보안 수준들이 이용될 수 있게 하는, 현장에서 업그레이드가능한 능력을 허용한다. 해커(haker)가 상기 보안을 파괴할 경우에, 그러한 시스템은 상기 매개변수들을 변경하고 상기 애플리케이션을 다시 컴파일함으로써 해커들에게 새로운 시도들 및/또는 추가적인 시도들을 제공하도록 응답할 수 있다.

현재 바람직한 실시예들은 각각의 애플리케이션에 대해 다수의 보안 조치를 허용하면서, 다른 여러 보안 구현들의 사용을 가능하게 해 준다. 이는 한 구현에 관한 성공적인 공격이 화이트-박스 암호화를 이용하는 소정의 소프트웨어 애플리케이션의 전부 또는 대부분의 구현에 관한 성공적인 공격이 되지 못하게 하는데 유리하다.

일반적으로, 위에 개시된 실시예들은 소프트웨어 파일 내에 화이트-박스 암호화를 통합하기 위한 컴퓨터-구현 방법 및 시스템을 제공하며, 이는 API들과 애플리케이션 또는 파일을 암호화, 난독화(obfuscating), 또는 다른 방식으로 보호하는데 사용되는 매개변수들을 분리하는 것을 포함한다. 그러한 통합 개발 슈트의 특정 이점은, 상기 애플리케이션에 적용될 수 있으며 상기 화이트-박스 암호화 구현에 의해 파악되는 데이터 변환들의 사용을 통해 암호화 애플리케이션들 및 주변 애플리케이션 간의 경계들을 보호하는 것이다.

이하의 내용에서는, 설명을 위해, 본 발명을 완전히 파악하도록 다수의 세부사항이 기술된다. 그러나, 이와 같은 특정의 세부사항들이 본 발명을 구현하는데 필요하지 않다는 점은 당업자에게 자명해질 것이다. 다른 경우들에서는, 공지된 전기적 구조들 및 회로들이 본 발명을 불명료하지 않게 하도록 블록도의 형태로 도시되어 있다. 예를 들면, 본원 명세서에 기술된 본 발명의 실시예들이 소프트웨어 루틴으로서 구현되는지, 하드웨어 회로로서 구현되는지, 펌웨어로서 구현되는지, 또는 이들의 조합으로서 구현되는지에 대한 특정의 세부사항들이 제공되지 않을 것이다. 본 발명의 실시예들은 (또한 컴퓨터-판독가능 매체, 프로세서-판독가능 매체, 또는 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터-사용가능 매체로서 언급되는) 기계-판독가능 매체에 저장된 소프트웨어 생성물로서 표현될 수 있다. 상기 기계-판독가능 매체는 디스켓, 콤팩트 디스크 판독 전용 메모리(CD-ROM), (휘발성 또는 비-휘발성) 메모리 장치, 또는 유사한 저장 메커니즘을 포함하는 마그네틱, 광학식, 또는 전기적 저장 매체를 포함하는, 임의의 적합한 유형(有形; tangible) 매체일 수 있다. 상기 기계-판독가능 매체에는 여러 세트의 명령어들, 코드 시퀀스들, 구성 정보, 또는 다른 데이터가 수록될 수 있는 데, 이는, 실행될 때, 프로세서로 하여금 본 발명의 한 실시예에 따른 방법의 단계들을 수행하게 한다. 당업자라면 이해할 수 있겠지만 앞서 기술된 본 발명을 구현하는데 필요한 다른 명령어들 및 동작들이 또한 상기 기계-판독가능 매체 상에 저장될 수 있다. 상기 기계-판독가능 매체로부터 실행하는 소프트웨어는 앞서 기술된 태스크들을 수행하도록 회로와의 인터페이스가 가능하다.

본원 명세서 전반에 걸쳐, "화이트-박스(white-box)"라는 용어는 "화이트-박스 호출(white-box call)", "화이트-박스 라이브러리(white-box library)", "화이트-박스 기능(white-box function)" 등과 같은 용어들을 만들도록 종종 접두어로 사용된다. 그와 같은 접두어로서 사용되는 경우에, "화이트-박스"라는 용어는 "화이트-박스 공격자에 대한 보안을 제공하도록 설계된 암호화 구현"에 대한 속기(速記)이다. 마찬가지로, "화이트-박스 암호화"라는 용어는 그 자체가 "화이트-박스 공격자에 대한 보안을 제공하도록 설계된 암호화 구현"에 대한 속기이다. 명확하게 말하자면, 어떠한 경우에도 "화이트-박스" 접두어는 그 항목 자체를 언급하지 않는다. 다시 말하면, 위에 기술된 실시예들이 소프트웨어 환경에서 기능하기 때문에, 상기 실시예들 및 사용자의 애플리케이션이 공격자에게 공개된 것임은 당연하다. 다른 말로 하면, 상기 실시예들 및 사용자의 애플리케이션은 화이트-박스이다. 실제로는, 이러한 용어들이 단지 또다른 속기일 뿐이다. 예를 들면, "화이트-박스 라이브러리"는 화이트-박스 공격자들에 대한 보안을 제공하는 암호화 기능들의 구현들을 포함하는 라이브러리이거나, 약간 더 간단하게는 화이트-박스 암호화를 포함하는 라이브러리이다(여기에서 우리는 "화이트-박스 라이브러리"가 이렇게 이중 속기가 되는 방식을 살펴 본 것이다). "화이트-박스 기능"은 화이트-박스 라이브러리의 기능들 중 하나이다. "화이트-박스 기능 호출", 또는 단지 "화이트-박스 호출"은 화이트-박스 기능에 대한 호출이다. 다른 용어들도 마찬가지로 해석되어야 할 것이다.

위에 기술된 실시예들은 화이트-박스 암호화를 소프트웨어 개발 슈트 내에 통합한 것이다. 도 1을 참조하면, 매우 높은 수준에서, 본 발명에 따른 애플리케이션 내의 화이트-박스 암호화의 통합은 자신의 애플리케이션 전반에 걸쳐 결정적인 보안 매개변수들의 암호화 기능과 흐름에 대해 사용자가 다수의 선택을 기능적이고 견고성과 관련되게 하는 것을 포함한다. 참조번호(100)로 도시된 바와 같이, 사용자가 (

으로 도시된) 추상된 호출들을 화이트-박스 API에 추가하여 원하는 암호화 기능을 구현하고, 또한 자신의 코드에 걸쳐 커맨드들을 추가하여 결정적인 보안 매개변수들에 필요한 보호를 확인한다. 그리고 나서, 다수의 화이트-박스 도구들 및 라이브러리들 사용하여(단계(102)), 견고한 코드(104)가 생성되는데, 이는 화이트-박스 라이브러리(108)에 컴파일 및 링크(단계(106))됨으로써 실행가능 파일(109)이 생성되게 하며, 상기 실행가능 파일(109)은 안전한 방식으로 암호화 동작들을 수행하고, 상기 애플리케이션의 전체 데이터 흐름에 걸쳐 결정적인 보안 매개변수들을 보호한다.

그러나, 개념적으로는, 사용자가 먼저 자신의 애플리케이션에서 암호화 기능 및 키 흐름에 대한 가장 기본적인 선택들을 취하여 구현한 다음에, 기능성 매개변수들을 정제(refine)하고, 마지막으로 견고성을 추가하는 조치를 취하는 진화(evolution)로서 상기 프로세스를 파악하는 것이 더 쉽다. 각각의 스테이지(stage)에서는, 상기 애플리케이션을 빌드 및 테스트(build and test)할 가능성이 존재하고, 최후에는 사용자가 견고한 애플리케이션을 튜닝(tuning)하고 선택적으로는 각각의 빌드를 개인화한다. 이와 같이 확장된 설계 흐름은 도 2에 도시되어 있으며, 스텁 빌드(stub build)(110), 유연한 빌드(smooth build)(112), 및 견고한 빌드(robust build)(114)를 포함한다. 상기 스텁 빌드(110) 및 유연한 빌드(112)는 선택적이며, 단지 넓은 용어들로만 기술된다. 그들의 구현이 당업자에게는 명확하겠지만 설계상의 선택이며, 단지 본 발명에 따른 화이트-박스 애플리케이션 개발 흐름의 실시예를 예시할 목적으로만 본원 명세서에서 논의될 것이다.

상기 스텁 빌드(110)에서, 사용자는 화이트-박스 기능 호출들을 적합한 화이트-박스 암호화 API들에 추가하여 입력 소스 파일(100)을 생성하도록 대칭 암호화, 비대칭 암호화 및 해싱과 같은 기능을 추가한다. 사용자는 화이트-박스 스텁 라이브러리(118)에서 정의된, 화이트-박스 호출들의 스텁 구현들에 대해 자신의 프로그램을 컴파일 및 링크(단계(116)시켜서, 실행가능 스텁(120)을 생성하는데, 이는 그후 키 흐름의 기본 오류와 아울러, 컴파일 및 링크 오류들에 대한 검사를 위해 테스트(단계(122))될 수 있다. 상기 스텁 라이브러리(118)에서 구현된 스텁 암호화 기능들은 단순하지만 복화화 및 암호화라는 양자 모두의 기능들에 대해 매칭 매개변수들이 전달되지 않는 한은 복호화 및 암호화가 서로 역의 관계인 것과는 다른 방식으로 구성된다. 예를 들면, 동적 키(dynamic-key) 복호화는 원래의 메시지를 복구시키기 위해 동적 키 암호화와 같은 키를 사용해야 한다. 이러한 키들이 동일한 것이 아닐 경우에, 부호화 오류로 인해, 스텁-복호화는 원래의 메시지를 생성하도록 스텁 암호화의 결과를 제대로 복호화시킬 수 없다.

상기 유연한 빌드(112)에서, 사용자는 각각의 호출을 매개변수화하도록 몇 가지 초기의 기능-관련 선택들을 하고 그러한 선택들을 열거하는 화이트-박스 매개변수화 파일(124)을 생성한다. 그리고 나서, 사용자는 행해진 선택들을 적용하도록 코드 생성 도구를 적용(단계(126))하고, 화이트-박스 라이브러리(130)의 유연한 버전에서 정의된 화이트-박스 호출들의 유연한 구현들에 대해 자신의 프로그램을 컴파일 및 링크(단계(128))시킨다. 상기 화이트-박스 라이브러리(130)의 유연한 버전은 단순히 진정한 화이트-박스 라이브러리와 같은 API를 구현하지만, 유연한 라이브러리를 언급한다. 그 결과로 얻어진 실행가능 유연한 버전(132)은 그후 기본적인 기능이 제대로 작동되게 하도록 테스트(단계(134))될 수 있다.

상기 견고한 빌드(114)에서, 사용자는 자신의 보호 애플리케이션의 크기, 속도 및 보안성의 조절(trade-off)들에 대한 선택들을 한다. 사용자는 이하에서 열거되는 화이트-박스 암호화 도구들을 적용(단계(136))하여 견고한 변환 코드(138)를 생성한다. 상기 견고한 변환 코드(138)는 그후 화이트-박스 라이브러리(144)의 화이트-박스 호출들의 안전한 구현들에 대해 컴파일 및 링크(단계(140))되어 보호 실행가능 구현(146)이 생성되게 한다. 이러한 보호 실행가능 구현이 기능 및 보안성 모두를 보장하기 위해 테스트(단계(147))될 수 있다. 사용자는 그후 보다 '경량인 프로세스(lightweight process)를 사용하여 개인화를 위해 다양한 여러 데이터 인스턴스들(149)을 선택적으로 생성(단계(148))한다.

상기 견고한 빌드 프로세스 및 구성요소들은 지금부터 도 5 및 도 6을 참조하여 더 상세하게 기술될 것이다. 도 5는 견고한 빌드의 간략화된 개요를 제공하며, 도 6은 이하에서 상세하게 기술되는 세부 구현의 실시예를 보여준다.

도 5의 실시예는 보호 파일, 예를 들면, 소프트웨어 애플리케이션 파일을 생성하는 3개의 모듈, 즉 화이트-박스 코드 생성 도구(

)(150), 데이터 변환 엔진(

)(152), 및 화이트-박스 데이터 생성 도구(

)(154)를 포함한다. 화이트-박스 암호화 콘텍스트에서, 상기 데이터 변환 엔진(152)은 상기 암호화 동작 및 주변 코드 간의 경계를 보호하는데 사용된다. 특히, 상기 데이터 변환 엔진(152)은 상기 암호화 동작들로의 입력들 상기 암호화 동작들로부터의 출력들에 대해 데이터 변환들을 적용하는 데 사용된다. 상기 화이트-박스 매개변수화 파일(124)을 통한 변환들의 요구를 사용자가 지정할 경우에,

(150)은 사용자에 의해 지정된 정보를 상기 데이터 변환 엔진(152)이 파악하는 형태로, 다시 말하면 데이터 변수들 및 기능 '프로토타입(prototype)'들에 관한 수식어(qualifier)들로서 적용한다. 상기 데이터 변환 엔진(152)은 그후 지정된 변환들을 적용하고, 변환들이 선택된 것에 관한 정보를

(154)에 전달한다.

이를 달성하기 위한 데이터 흐름이 도 5에서는 높은 수준으로 도시되어 있다. 상기 화이트-박스 코드 생성 도구(150)는 애플리케이션 소스 코드 및 추상화된 화이트-박스 기능 호출들을 포함하는 적어도 하나의 입력 소스 파일(100) (

; 사용자 코드), 및 각각의 추상화된 화이트-박스 기능 호출에 대한 암호화 도메인 매개변수들을 포함하는 매개변수화 파일(124)을 수신한다. 상기 화이트-박스 코드 생성 도구(150)는 이러한 입력들을 처리하여 각각의 추상화된 화이트-박스 기능 호출의 암호화 도메인 매개변수들에 따라 그리고 상기 데이터 변환 엔진(152)에 의해 파악되는 방식으로 각각의 추상화된 화이트-박스 기능 호출을 정의하는 화이트-박스 호출 정의 데이터(156)(

)를 생성한다. 상기 데이터 변환 엔진(152)은 그후 하나 이상의 데이터 변환들을 상기 입력 소스 파일(100) 및 상기 화이트-박스 호출 정의 데이터(156)에 적용하여 변환된 소스 파일(160) 및 변환된 화이트-박스 호출 정의 데이터(158)(

)를 생성한다. 상기 데이터 생성 도구(154)는 그후 상기 변환된 화이트-박스 호출 정의 데이터(158)에 따라 각각의 화이트-박스 기능 호출에 대해 인스턴트-특정 데이터를 포함하는 데이터 초기화들(162)(

)을 생성한다. 상기 데이터 초기화들(162) 및 상기 변환된 소스 파일(160)은 그후 원래의 컴파일러를 사용하여 컴파일되고 화이트-박스 라이브러리에 링크된다.

화이트-박스 API

일단 사용자가 자신의 애플리케이션에서의 암호화에 대한 필요성을 확인하면, 사용자는 API에 대한 각각의 호출에 대하여 자신이 취할 선택을 2가지 갖는다. 이러한 선택들은 자신의 애플리케이션의 기본 키 흐름을 결정하게 된다. (1) 수행될 암호화 동작이 무엇인가? 가능한 동작들에는 암호화, 복호화, 서명, 서명 검증, 해싱 등이 있다. (2) 이러한 호출에 대한 키가 단지 실행-시간에만 이용가능한 것인가? 아니면 이러한 호출에 대한 키가 그 이전에 이용가능한 것인가? 세션 키들 또는 콘텐츠 키들과 같은 키들은 대개 동적으로 생성되거나 비대칭 복호화의 결과로서 연산된다. 우리는 그러한 키들을 넓게 동적인 것으로 지칭할 것이다. 그 반면에, 빌드 시간(build-time)에 알려져 있거나 어떤 오프-라인 가입/갱신 프로세스를 통해 획득될 수 있는 키들은 고정 키(fixed key)들로 지칭될 것이다. 확실한 점은, 모든 키들이 동적인 것으로 취급될 수 있지만 키들이 고정된 것으로 취급될 수 있는 경우, 그러한 경우에도 보안 이점이 있다는 점이다.

일단 위의 결정들이 내려지면, 사용자 애플리케이션 코드가 그러한 선택에 적합한 API를 호출하도록 작성될 수 있다. 상기 입력 소스 파일(100)인 사용자 애플리케이션은 최소한의 API를 사용하여 키 스케줄링, 암호화, 복호화 등과 같은 암호화 동작들의 호출들을 포함하는 (C 또는 C++에서와 같은) 소스 코드로 이루어진다. 암호텍스트, 평문텍스트, iv 등과 같은 키 사용자-제공 데이터는 관련 호출들을 단일의 암호화 도메인으로 그룹화하는데 사용되는 실수 상수(numeric constant)

매개변수와 함께, 이러한 호출들에 매개변수들로서 전달된다. 바람직한 실시예에서, 사용자 애플리케이션-코드는 화이트-박스 타입들 및 매크로(macro)들을 정의하는 포함 파일(include file; 170)(

)을 포함할 필요가 있게 된다. 모든 암호화 동작들은 이러한 포함 파일(170)로부터의 매크로들을 사용하여 호출될 수 있다. 바람직하게는, 상기 화이트-박스 포함 파일(170)(

)은 모든 암호 타입들에 대한 암호화 동작들 각각에 대해 단일의 매크로 정의를 제공한다. 매크로들은 매개변수들로서 최소 세트의 사용자-공급 매개변수들(전형적으로는 평문텍스트/암호텍스트와 같은 애플리케이션 데이터), 동작의 암호화 도메인을 확인하도록 하는) 단일

매개변수, 및 선택 매개변수를 취한다. 예를 들면, 블록 암호 부호화 호출이 이하에 제시되어 있다. 매크로 호출(

)은 매우 추상화된 것이며 단지 암호화 동작에 필요한 실제 애플리케이션 데이터만을 지정한 것임에 유념하기로 한다.

상기 화이트-박스 포함 파일(170)(

)은 사용자의 애플리케이션 코드의 관점에서 전체 화이트-박스 API를 정의한다. 이러한 API는 애플리케이션 코드에서의 사용을 위해 이용가능한 모든 추상화 암호화 동작들을 정의하는 유사 기능(function-like) 매크로들의 형태를 이룬다. 더욱이, 이러한 포함 파일(170)은 또한 매크로 정의들의 형태로 이하에 기술되는, 화이트-박스 글루(white-box glue) 파일들의 콘텐츠를 기술한다. 이하의 전형적인 코드 '스니펫(snippet)'들은 고정-키(Fixed-Key), 블록-암호 부호화(Block-Cipher Encrypt) 동작에 대한, 단일의 추상화 API의 높은 수준 세부사항들을 보여준다:

종종, 암호화 기능들은 별도로 수행되지 않는다. 그 대신에, 애플리케이션은 대개 계층 구조에서 일련의 키들을 포함하며, 암호화 동작들은 계층 구조에서 최하위 키들이 콘텐츠를 보호하는데 사용되고 보다 귀중한 키들이 하위 레벨 키들을 보호하는데 사용되게끔 연쇄(chaining)되어 있다. 계층 구조의 맨 위에는 하나 이상의 "신뢰할 수 있는 루트(roots of trust)" 키들이 있게 되며, 이러한 키들이 폭로되면 다른 모든 키가 노출됨으로써, 완벽한 보안 파괴가 초래된다.

계층 구조의 간단한 예는 콘텐츠 키라고 불리는 랜덤 키(random key)를 통한 AES 암호화를 사용하여 보호되는, 음악 파일과 같은 콘텐츠를 지니는 것이다. 상기 콘텐츠 키 자체는 클라이언트-특정 공개 키를 통한 RSA 암호화를 사용하여 보호된다. 상기 신뢰할 수 있는 루트는 이때 클라이언트 애플리케이션의 일부인 (종종 고정된) RSA 개인 키이다. 이러한 계층 구조는 도 3에 도시되어 있다. 일반적으로 한 암호화 동작의 출력은 후속 암호화 동작에 대한 입력들 중 하나가 되는 임의의 시나리오는 연쇄된 암호화라고 언급된다. 자주 나오는 연쇄된 암호화의 또다른 예는 또한 트랜스크립션(transcryption)으로서 알려져 있다. 이는 한 알고리즘 및 키를 사용한 특정 콘텐츠의 복호화에 이어서, 또다른 알고리즘 및 키를 사용한 그와 동일한 콘텐츠의 즉각적인 재-암호화를 포함한다. 이는 종종 서로 통신하는 2개의 프로그램 간의 경계에서, 또는 소프트웨어 및 하드웨어 간의 경계에서 이루어진다.

하나의 동작, 다시 말하면 2가지 동작 간의 경계에서 노출되는 것과는 반대로, 한 동작으로부터 다음 동작으로 전달되는 값이 완전히 은닉될 수 있는 단일 동작으로서 연쇄된 암호화 동작들을 고려한다는 점에서 별개의 보안상의 이점이 있다. 동작들 간의 경계에서 이러한 값을 변환시키는 것도 물론 가능하고, 보호 기능을 제공하지만, 연쇄된 동작들의 진정한 블렌딩(blending)은 적용될 수 있는 보안 기술들에 있어서의 보다 큰 유연성을 제공함으로써, 더 나은 전반적인 보호 기능을 제공한다.

본원 명세서에서 기술되는 화이트-박스 기반구조 및 API는 다수의 연쇄된 암호화 시나리오들을 지원하도록 용이하게 확장될 수 있다. 특정 예가 이하에 제공되어 있다. 이러한 예는 RSA 및 AES 복호화들을 단일의 연쇄된 복호화로 조합하도록 수정된 도 3의 클라이언트 측에 해당한다. 도 4는 이러한 변경 사항을 보여준다. 여기서 유념할 점은 복호화된 콘텐츠 키가 이 도면에는 더이상 나타나 있지 않다는 점이다. 이러한 예는 단지 예시적인 것뿐이다.

화이트-박스 매개변수화

일단 사용자가 자신의 키 흐름을 검증한 경우, 사용자는 각각의 화이트-박스 암호화 기능 호출을 부가적으로 매개변수화하도록 일련의 기능 선택들을 해야 한다. 이러한 질문들 대부분은 암호로 특정되지만, 일반적인 질문들 중 특정 예들은 (1) 어떤 알고리즘이 필요한가? 종종, 사용해야 할 알고리즘은 특정의 관련 표준에 의해 지정된다. (2) 어느 정도의 키의 크기가 필요한가? 여기에서의 유효한 선택들은 상기 알고리즘에 의존한다. 이러한 결정들은 사용자-제공 화이트-박스 매개변수화 파일(124)에서 획득되며, 상기 사용자-제공 화이트-박스 매개변수화 파일(124)은 그후, 실행가능 파일을 빌드하기 위해, 사용자의 소스 코드와 함께 처리된다.

(어떤 알고리즘도 사용할 정도로 기본적이고 어떤 키도 사용할 정도로 세부적인) 암호화 동작들의 특정 태양들에 대해 사용자가 선택들을 하는 주요 메커니즘은 화이트-박스 매개변수화 파일(124)을 통해 이루어진다. 사용자에 의해 작성되는, 이러한 파일은, 각각의 호출에 대한 세부사항들을 화이트-박스 기능에 제공한다. 한 실시예에서, 상기 화이트-박스 매개변수화 파일(124)의 포맷은 암호화 도메인 매개변수 이름들 및 암호 도메인 매개변수 값들로 이루어진 라인 지향(line-oriented) 텍스트이다. 이러한 매개변수 이름/값 쌍들(이하 "암호 도메인 매개변수들" 또는 간단히 "매개변수들"로 지칭함)은 개별 화이트-박스 매개변수화 레코드들을 만들기 위해 그룹화된다. 각각의 레코드의 개시는 식별자(

) 매개변수의 존재에 의해 구분되며, 식별자(즉, 파일의 종료)가 다음에 발견될 때 끝나게 된다. 매개변수화 레코드의 범위 내에서, 임의 개수의 고유 매개변수들은 리스트화될 수 있다(임의 매개변수 이름의 중복은 오류이다). 당업자라면 이해되겠지만, 특정 매개변수들이 생략될 수 있으며 디폴트 값들을 지닐 수 있지만, 다른 매개변수들은 필수적인 것으로 제공되어야 한다. 어떠한 경우에도, 개별 매개변수의 범위는 단지 현재의 매개변수화 레코드에 대한 것뿐이다.

매개변수의 값은 화이트-박스 호출들을 식별하는 데 사용된다. 이 때문에, 다음과 같은 사항이 바람직하다.

1.

는 소정 호출이 상기 매개변수 파일(124) 내의 소정 레코드에 일관해서 매핑되도록 리터럴 정수 상수(literal integer constant)이다.

2. 각각의 호출은 상기 매개변수화 파일(124) 내의 소정 레코드가 고유 호출에 매핑되도록 고유

로 주어진다. 이러한 규칙에 대해 예외들이 있을 수 있다.

a. 데이터를 공유하도록 선택되는 호출들은 동일한

로 주어줘야 한다.

b. 기타 암호-특정 예외들.

각각의 ID에 대해, 상기 화이트-박스 매개변수화 파일(124)은 하나의 레코드를 포함하게 되며, 이는 상기 파일의 라인에 대해 하나의 매개변수가 리스트되게끔 그러한 레코드에 연관된 특정 매개변수들을 리스트화하게 된다. 하나의 화이트-박스 레코드의 매개변수들은 3가지의 광범위한 카테고리로 나뉘어질 수 있다.

ㆍ카테고리화 매개변수들: 이들은 블록 암호 또는 비대칭 암호, 및 고정 키 대 동적 키와 같은, 이용될 암호화 알고리즘의 카테고리를 기술한다. 이러한 매개변수들은 이중 목적을 제공한다. 다시 말하면, 첫째로, 상기 매개변수들은, 사용자가 매개변수화 레코드를 보고 해당하는 화이트-박스 호출의 동작이 어떤 것임을 정확하게 안다는 점에서, 매개변수화 파일 레코드가 독립적이게 하고, 둘째로, 상기 매개변수들은 오류 검사를 허용하여, 이러한 매개변수들의 사양으로서 어떤 사용자-제공 매개변수들이 예상되는지를 정확하게 결정한다.

ㆍ기능성 매개변수들: 이들은 회전의 횟수와 같은 이용될 암호화 알고리즘의 특정 속성들을 기술하고, 매개변수들 또는 선택들로서 화이트-박스 API에 전달되게 한다(이는 자동으로 이루어지며 최종 사용자에게 투명하다). 여기서 유념할 점은 알고리즘이 카테고리화 매개변수로 간주되는 것이 아니라 기능성 매개변수(예컨대, 알고리즘=AES 대 알고리즘=DES)로 간주된다는 점이다.

ㆍ견고성 매개변수들: 이들은 선택 매개변수들을 통한 변환들과 같은, 화이트-박스 호출의 견고성 특징들에 관한 특정 결정들을 기술한다.

가장 높은 수준의 카테고리화 매개변수는 FunctionType이다. 기타 유효한 매개변수들은, 기능성 및 견고성 매개변수들과 아울러, FunctionType에 대해 지정된 값에 의존한다. 이하의 예는 블록 암호에 대한 전형적인 화이트-박스 매개변수 '설정항목(entry)'을 보여준다. 리스트화되는 매개변수들 대부분은 암호로 특정된 것이며 그들의 의미는 본원 명세서에 기술되지 않을 것이다.

이 시점에서, 사용자는 다수의 보안 관련 선택들을 해야 한다. 가능하다면, 화이트-박스 암호화 기능에 대한 호출로의 모든 입력들 및 화이트-박스 암호화 기능에 대한 호출로부터의 모든 출력들은 변환되어야 한다. 특히 블록 암호들에 대해, 평문텍스트, 암호텍스트, (동적 키 기능들에 대한) 키 및 (ECB와는 다른 모드들에 대한) 초기화 벡터는 변환되어야 한다. 일례로서, 보안의 증가 순서로 이루어진 세트의 이용가능한 변환들은 다음과 같을 수 있다.

바람직하게는, 모든 데이터 변환들이 입력들 및 출력들상에서 사용될 수 있다. 사용자는 상기 화이트-박스 매개변수화 파일(124)에서의 입력들 및 출력들에 대해 논리 변환 타입들을 지정할 수 있다. 예를 들면, 사용자는 소정

에 대해 다음과 같은 설정항목: PlainTransform blue을 지정할 수 있다. 이는 소정

에 해당하는 호출의 평문텍스트가 "블루(blue)" 논리 변환 타입을 사용하여 변환될 것임을 나타낸다. 변환될 모든 암호 입력들 및 출력들은 화이트-박스 매개변수화 파일(124)에서 적합한 Transform 설정항목을 지녀야 한다. 화이트-박스 기능들 대부분, 가장 주목할 만한 것으로 화이트-박스 AES는 다른 여러 방식으로 구현될 수 있다. 암호화 타입으로서 알려져 있는 이러한 방식들 각각은 크기, 속도 및 보안성 간의 서로 다른 조절이 이루어지게 한다. 사용자는 상기 화이트-박스 매개변수화 파일(124)에 리스트화된 각각의 논리 변환 타입에 대한 변환 타입 매핑을 제공할 책임을 갖는다. 이는 대개는 구성(config) 파일을 통해 이루어지지만, 또한 커맨드 라인상에서 직접 공급될 수도 있다.

위에 기술된 바와 같이, 화이트-박스 호출 및 매개변수화 파일 레코드(결과적으로는 인스턴스-특정 세트의 코드 및 데이터) 간의 접속은

매개변수이다. 따라서, 동일한 기능에 대한 2가지 호출이 상기

매개변수에 대해 동일한 값으로 주어지면, 상기 동일 기능에 대한 2가지 호출은 동일한 화이트-박스 매개변수화 파일 레코드를 참조하게 되며, 궁극적으로는 동일한 화이트-박스 라이브러리 호출로 해결해 줌으로써, 그러한 호출에 연관된 데이터를 공유하게 된다. 다른 말로 하면, 2개의 화이트-박스 호출이 데이터를 공유하게 하기 위해, 2개의 화이트-박스 호출은 동일한

로 주어질 수 있다. 여기서 유념할 점은 2개의 화이트-박스 호출이 동일한 추상화된 API에 대한 것인지 그리고 또한 입력들 및 출력들에 관한 데이터 변환들이 동일한 것인지를 공유된 데이터만으로 알게 된다는 점이다.

사용자가 화이트-박스 암호화 호출에 대한 데이터를 외부에 저장하도록 선택한 경우에는, 외부 데이터를 검색하고 이를 적합한 형태로 적용하도록 추가되는 해당하는 호출이 있어야 한다. 예를 들면, 고정 키 블록 암호 암호화(fixed-key block cipher encrypt) 예는 다음과 같이 향상될 수 있다.

전형적인 입력 소스 파일:

전형적인 매개변수화 파일(

)

화이트-박스 코드 생성

공격들을 방지하는 어려움들 중 하나는 상기 화이트-박스 암호화 구현 자체가 키를 대체할 수 있다는 것이다. 상기 화이트-박스 소프트웨어 구현이 부분적인 평가로 키를 엠베드(embed)하고, 복호화를 구현할 경우에, 그 전체의 애플리케이션이 복호화를 수행하는데 상기 키 대신에 사용될 수 있다. 즉, 어떤 암호가 구현되고 있는지 그리고 그 키가 어떤 것인지를 결정하는 대신에, 공격자는 간단하게 그 전체의 화이트-박스 복호화 구현을 추출하고 이를 복호화를 위해 사용할 수 있다. 이는 화이트-박스 복호화의 '코드-리프팅(code-lifting)' 또는 '스니핑(snipping)' 이라 불린다.

그러한 공격들에 대해 방어하는 복잡성은 화이트-박스 암호화를 이용하는 시스템들의 페리-크립틱(peri-cryptic) 태양 및 인터-크립틱(inter-cryptic) 태양을 자동화하기 위한 이점들의 좋은 예를 제공한다. 예를 들면, 화이트-박스 암호화 구현들은 데이터 배열들을 이용한다. 그러한 배열들 또는 테이블들을 '스니핑'으로 제거하기 어렵게 하기 위해, 각각의 테이블은 2개의 부분으로 분할될 수 있다. 한 부분은 상기 화이트-박스 구현의 외부 소프트웨어 어딘가에 있는 실행가능 코드의 세그먼트이다. 나머지 하나는, 그러한 코드 세그먼트의 해당 부분과 배타적 논리합(exclusive-or)'으로 연산될 때 원하는 테이블을 만들어내는 'xor' 데이터를 포함하는 동일 크기의 데이터 테이블이다. 이는 단지 필요한 데이터 세그먼트가 존재할 경우에만 화이트-박스 코드가 올바르게 실행하기 때문에 화이트-박스 코드를 리프팅하는 것을 어렵게 한다. 또다른 방법은, 화이트-박스 구현의 외부 데이터 없이는, 상기 화이트-박스 내부의 데이터 배열들이 쓸모 없게 하도록 상기 코드 세그먼트를 상기 화이트-박스 암호화 구현 외부의 다른 애플리케이션 데이터로 대체하는 것이다. 여전히 또다른 방법에서는, 데이터 테이블들이 화이트-박스 암호화를 이용하는 프로그램 전반에 걸쳐 산란된 위치들에 액세스하는 테이블들로 대체될 수 있다. 각각의 데이터 테이블은 그후 적합한 데이터 부분들이 발견될 수 있는 프로그램의 나머지의 코드 또는 데이터 전반에 걸친 여러 위치에 대한 포인터 테이블로 대체된다. 다시 말하면, 각각의 원래 테이블은 원하는 원래 데이터를 포함하는 위치에 대한 포인터 테이블로 대체된다. 이러한 방법들은 실행가능 코드를 편집하고 원래 테이블을 'xor' 데이터로 대체하거나 이와는 달리 상기 테이블들을 수정하기 위해, 상기 애플리케이션의 나머지의 컴파일된 2진 코드를 액세스하는 여러 도구, 및 매우 유능한 프로그래머를 필요로 한다. 상기 화이트-박스 코드 생성 도구(150)는 그러한 방법들을 자동화하여 "글루(glue)" 코드를 생성함으로써 암호화 동작의 경계에서의 입력들 및 출력들이 유효하게 난독화되게 한다.

일단 상기 매개변수화 파일(124)이 만들어진 경우에, 사용자는 화이트-박스 코드 생성 도구(150)를 실행하여야 하며, 상기 화이트-박스 코드 생성 도구(150)는 상기 매개변수 파일(124)을 파싱(parsing)하고 상기 화이트-박스 라이브러리로의 적합한 호출들을 이루게 하는 화이트-박스 호출 정의 파일(172)을 생성한다. 상기 화이트-박스 코드 생성 도구(150)가 이후로는

(150)로 언급될 것이다.

(150)은 주로, 상기 화이트-박스 매개변수화 파일(124)과 함께 상기 사용자 애플리케이션-코드(특히, 상기 화이트-박스 암호화 API들에 대한 호출들을 포함하는 파일들)를 처리하고, 상기 데이터 변환 엔진(152)에 의해 파악될 수 있는 변환 수식어들을 포함하는 (또한 본원 명세서에서는 화이트-박스 호출 정의, 또는 "글루(glue)", 파일들이라 언급되는) 화이트-박스 호출 정의 데이터를 생성할 책임을 갖는다. 상기 화이트-박스 호출 데이터는, 사용자 애플리케이션에서 사용되는 높은 수준으로 추상화된 API 및 상기 화이트-박스 라이브러리에서 제공되는 낮은 수준의 화이트-박스 루틴들 간에 매핑하는 "글루(glue)" 루틴들의 한 세트의 기능 정의들을 제공한다.

상기

도구(150)는 사용자의 소스-코드에서의 화이트-박스 API들의 호출에 기반한 화이트-박스 글루 코드의 생성, 및 상기 화이트-박스 매개변수화 파일(124)에 포함된 암호화 도메인들의 기술(description)에 대한 책임을 갖는다. 상기 화이트-박스 글루 코드는 사용자의 소스-코드에서의 높은 수준으로 추상화된 API 및 화이트-박스 라이브러리 암호화 동작들의 실제 호출 간의 쐐기(shim)로서의 역할을 하고, 화이트-박스 매개변수화에 대한 변경들이 이루어질 때 사용자 소스-코드가 수정될 필요가 없게 한다.

(150)은 처리 속도를 개선하도록 프리-프로세서(pre-processor)의 확장으로서 설계될 수 있다.

(150)은 상기 데이터 변환 엔진(152)으로부터 완전히 분리되는 것이 바람직하다.

(150)은 결코 상기 사용자 애플리케이션-코드를 수정하지 않으며,

(150)이 생성하는 화이트-박스 글루 파일들은 최종 애플리케이션 내로 컴파일 및 링크되도록 의도된 별도의 소스 파일들로 이루어지는 것이 바람직하다. 그 외에도,

(150)은 (매개변수 이름들이 적법한 것이고 매개변수 값들이 유효한 것임을 검사하며, 그리고 한 레코드 내에서 지정된 매개변수들을 일관성있게 검사하는) 화이트-박스 매개변수화 파일(124)에 대한 유효성 검사 도구로서의 역할을 한다. 마지막으로,

(150)은 또한, 사용자의 애플리케이션-코드(예를 들면, 블록 암호 동작에 관한 비대칭 암호를 언급하는

매개변수의 사양)에서의 화이트-박스 동작들에 대한 명시적 및 암시적 매개변수 오류들을 모두 포함하는 오류들을 검출하는데 사용될 수 있다.

(150)은 상기 매개변수화 파일(124), 및 화이트-박스 암호화 호출들을 포함하는 입력 소스 파일(들)(100)을 입력들로서 취한다. 그의 출력은 발견되는 각각의 화이트-박스 암호화 호출에 대한 정의들을 포함하는 화이트-박스 호출 정의 파일(172)(

)이다. 상기 도구는 또한 상응하는 화이트-박스 글루 헤더(174), 또는 단순히 헤더, 파일(

)을 생성하며, 이러한 헤더 파일은, 예를 들면 하나가

및 기본적인 암호화 동작의 조합에 대한 것인 한 세트의 "글루(glue)" 루틴들의 외부 선언(extern declaration)들일 수 있는 생성된 기능들 각각에 대한 프로토타입(prototype)들을 포함한다.

(150)은 또한 각각의 화이트-박스 호출에 대해 취해진 선택들에 관한 메타데이터를 유지하는 출력 화이트-박스 메타데이터 파일(176)을 생성하는데, 이러한 메타데이터는 이하에서 기술되는 데이터 생성 도구(154)(

)로 전달된다.

사용자는 상기 추상화된 화이트-박스 API들의 새로운 호출들에 대해 상기 애플리케이션 코드가 업데이트되는 경우마다, 또는 상기 화이트-박스 매개변수화 파일(124)이 수정될 경우에

(150)을 재-실행할 책임을 갖는다.

위에 기술된 바와 같이, 상기

도구(150)는 상기 화이트-박스 매개변수화 파일(124)과 함께 사용자의 소스-코드를 처리하고 사용자의 추상화된 화이트-박스 API 호출들을 낮은 수준의 화이트-박스 라이브러리 루틴들에 대한 완전히 매개변수화된 호출들로 확장할 책임을 갖는다. 상기

도구(150)는, 예를 들면 매개변수들을 수용 및 파싱할 최상위 수준의 펄 프런트 엔드(Perl front-end)(또는 드라이버)로 이루어질 수 있다. 상기 펄 프런트 엔드는 또한, 라인 지향(line-oriented) 텍스트 콘텐츠에서의 구문론적/의미론적 오류들을 검사하여 상기 매개변수화 파일 콘텐츠의 유효성을 검사하고, 이를 상기

백 엔드(back-end)에 수용가능한 형태로 변환할 수 있다. 상기

백 엔드는 상기 변환된 매개변수화 파일과 함께 사용자의 소스 코드를 처리할 수 있다.

상기

백 엔드가 수행해야 할 것 대부분은 매크로-확장과 매우 유사하다. 추상화된 화이트-박스 API의 모든 호출은

매개변수가 호출 이름의 일부로 이루어지게 되는 "망글(mangled)" 형태로 확장된다. 모든 화이트-박스 API 호출의 소스 위치는 별도의 메타데이터 파일에 레코드된다. 고유한 망글 이름(즉,

매개변수가 추가된 화이트-박스 API)의 최초 호출은 실제의 기본적인(underlying) 화이트-박스 라이브러리 기능을 호출하는 적합한 기능 정의의 생성을 트리거(trigger)한다. 여러 형태의 매개변수의 일관성 검사는 또한 수행될 수 있으며 컴파일/링크/실행 시간 전에 사용자-애플리케이션 및 매개변수화 파일(124)의 정확성을 보장하기 위해 오류들이 방출될 수 있다.

커맨드-라인 매개변수/선택 파싱은 펄 드라이버에 의해 수행될 수 있다. 상기 펄 드라이버는 매개변수 값들에 관한 새너티(sanity) 검사를 수행하게 되며, 선택적으로는 (도시되지 않은) 화이트-박스 매개변수 파일 프리-프로세서/유효성 검사 도구를 호출할 수 있다. 상기 드라이버는 그후 각각의 커맨드-라인 지정 소스-파일에 관한

백 엔드를 호출할 수 있다. 이러한 접근법의 한가지 복잡성은 몇몇 상태 정보가 상기

백 엔드의 호출들 사이에 존속해 있어야 한다는 것이다(특히, 이는, 고유한 글루-코드 기능 정의들을 적합하게 생성시킴과 아울러, 중복 호출에 대해 경고할 수 있도록 어느 화이트-박스 동작/

조합들이 이전에 처리된 소스 파일들에서 발견되었던 것인지를 알아야 한다.) 이러한 문제를 해결하기 위해, 상기

드라이버는, 각각의 백 엔드 호출에 전달되고 임의의 그러한 상태 정보를 포함하는 임시 파일을 열도록 설정될 수 있다. 이러한 임시 파일의 수명(lifetime)은

(150)의 한번 호출이며,

(150)이 종료하기 전에 제거될 수 있다. 이 때문에, 이러한 파일이 사용자에게는 전혀 가시화되지 않는다.

상기 화이트-박스 매개변수화 파일의 포매팅의 상대적인 복잡성 때문에, 매개변수들은 비록 존재하지 않는 경우에도, 다시 말하면 매개변수들이 디폴트 값들을 갖는 경우에도 몇몇 콘텍스트들에서 수반될 수 있거나 다른 매개변수 값들과의 조합으로 합법적이지 않을 수 있다. 그 결과로, 상기 매개변수화 파일(124)의 사전 처리(pre-processing)가

(150)의 파싱 전에 구현될 수가 있다. 사전 처리 도구는 펄 언어의 강력한 정규 표현 능력들 때문에 펄로 작성될 수 있다. (도시되지 않은) 화이트-박스 매개변수화 유효성 검사 도구는 상기 디폴트 값으로 레코드를 명시적으로 삽입함으로써 누락된 디폴트 매개변수들을 처리하도록 포함될 수 있으며, 매개변수 값들이 합법적이고 매개변수들의 조합들이 일관성이 있음을 확인하도록 포함될 수 있다. 이와 동시에, 상기 화이트-박스 매개변수화 프리-프로세서는 자유 포맷 텍스트

레코드들을 적합한 매크로 호출들로 변환할 수 있다.

전형적인 사용 시나리오는 다수의 입력 소스 파일들(100) 및 단일의 화이트-박스 매개변수화 파일(124)의 애플리케이션 빌드를 포함하는 것으로 생각되기 때문에, (상기 단일의 화이트-박스 매개변수화 파일(124)과 함께, 화이트-박스 API들에 대한 호출들을 포함하는 모드 소스 파일들을 입력으로서 취하는)

(150)의 호출이 한번 있게 된다는 것은 당연히 수반된다. 그러나, 설계상 어떠한 것도 상기 애플리케이션을 여러 모듈로 분할하는 것을 제외한 것이 아니며, 각각의 모듈이 자기 자신의 화이트-박스 매개변수화 파일(124)(또는 실제로는 모든 모듈들에 대한 단일의 공유 화이트-박스 매개변수화 파일(124))을 지니고, 이러한 모듈들 각각의 처리에는

(150)의 해당 호출들이 있게 된다.

일단 단일의 개발자가

(150)을 실행한 경우에는, 다른 개발자들이 자신들의 빌드들의 일부로서 상기

(150)을 재실행할 필요가 없다. 그 대신에, 위에 기술된 바와 같이 생성된 헤더 파일(174)을 포함하고 상기 생성된 파일을 빌드 스크립들에 추가할 수 있다. 그 시점에서, 애플리케이션을 컴파일 및 링크하고자 하는 어떤 사람은 단지 원래의 컴파일 도구들만을 필요로 한다.

화이트-박스 데이터 변환

일단 상기 코드 생성 도구(150)가 실행된 경우에는, 화이트-박스 호출들에 대한 입력들 및 출력들을 보호하기 위해 데이터 변환을 수행하는 것이 바람직하다. 도면들에서

로서 도시된 데이터 변환 엔진(152)은 상기 화이트-박스 기능 호출 정의들을 포함하는 글루 코드 및 상기 입력 소스 파일(들)(100)에 관해 이러한 기능(또한 본원 명세서에서 "트랜스코딩(transcoding)"으로서 언급됨)을 수행한다. 상기 Cloakware Transcoder^TM와 같은 데이터 변환 엔진(152)은 위에 기술된 구현들에서 데이터 변환들을 사용하여 상기 화이트-박스 기능을 제공하는 데 사용된다. 이러한 데이터 변환의 출력은, 클로킹(cloaking) 또는 난독화(obfuscating)된, 변환된 소스 파일(180)(

), 클로킹 또는 난독화된, 호출 정의 파일(182)(

), 및 외부 변환 메타데이터를 포함하는 파일(184)(glue metadata)이다. 상기 생성된 변환 메타데이터 파일(184)은 상기 화이트-박스 글루 기능들에 대해 선택되는 매개변수들에 관한 데이터 변환 선택들을 기술한다.

상기 화이트-박스 암호화 구현들은 애플리케이션 데이터(암호화에 대한 평문, 복호화에 대한 암호, 적절한 경우 암호 및 IV의 추가)에 관한 변환들이 상기 화이트-박스 호출의 범위 외에서 적용되었고, 그리고 초기 단계에서 그러한 변환들을 안전하게 제거하는 것을 가정한다. 마찬가지로, 출력 변수들(예컨대, 암호화에 대한 암호, 복호화에 대한 평문)에 관한 변환들이 상기 암호화 동작의 최종 단계들에서 안전하게 적용되고, 상기 데이터 변환 엔진(152)은 이러한 변수들 내의 데이터가 변환되는 것을 가정한다.

상기 데이터 변환 엔진(152)의 기능이 본원 명세서의 범위에서 벗어나 있지만, 일반적으로 데이터에 관한 변수들 및 수학적 동작들, 특히 암호화 동작들을 난독화 또는 클로킹하도록 데이터 변환을 적용하여, 이를 공격자에게 가시화되지 않게 하여 중요한 자산(assets)에 대한 정보 손실이 나타나지 않게 하는 것으로 이해될 수 있다. 상기 데이터 변환 엔진(152)은 또한 애플리케이션의 프로그램적 흐름을 위장하도록 제어 흐름 변환들을 적용하여, 공격자가 애플리케이션의 동작을 정적으로나 또는 동적으로 추적하기 매우 어렵게 할 수 있다. 상기 데이터 변환 엔진(152)은 소스 코드를 수학적으로 수정된 소스 코드로 변환시키는 유틸리티(utility)로 간주될 수 있다. 변환된 애플리케이션들은 기능적으로 원본들과 동일하지만, 역공학(reverse engineering) 및 변조(tempering) 공격들에 매우 내성이 강하다. 보호 애플리케이션은 특정 하드웨어 또는 추가적인 소프트웨어 없이 신뢰성있게 오픈 컴퓨팅 플랫폼(open computing platform)들 상에서 실행된다.

상기 데이터 변환 엔진(152)은 또한, 단지 개별적인 기술들뿐인 것보다 훨씬 더 안전한 통합되고 계층화된 보호를 하기 위해 화이트-박스 암호화를 코드 변환들과 링크시킨다. 세부사항들이 또한 본 내용의 범위를 벗어나 있는, 화이트-박스 암호화는, 공격자가 암호화 키를 획득하지 못하게 하는 방식으로 (또는, 비대칭 '공개 키' 암호화의 경우에, 공격자가 개인 키(private key)를 획득하지 못하게 하는 방식으로), 또는 해커들이 매우 세부적으로 암호화 동작들을 관찰할 수 있는 환경에서, 상기 키를 대체할 수 있는 무언가를 획득하지 못하게 하는 방식으로, 표준 암호화 알고리즘들을 구현한다. 화이트-박스 암호화는, 심지어 암호화 동작들 동안에도 결정적인 키 데이터가 누설되지 않게 하도록 RSA 및 AES와 같은 암호들을 구현할 수 있다.

데이터 변환 및 화이트-박스 암호화 구현들의 예들은, 미국 특허 공보 2004/0236955-A1의 '변조에 내성을 갖는 소프트웨어 부호화 및 분석(TAMPER RESISTANT SOFTWARE ENCODING AND ANALYSIS)'; 미국 특허 공보 2005/0039025-A1의 '소프트웨어 조건부 액세스 시스템(SOFTWARE CONDITIONAL ACCESS SYSTEM)'; 미국 특허 제7,325,141호의 '보안 액세스를 위한 방법 및 시스템(METHOD AND SYSTEM FOR SECURE ACCESS)'; 미국 특허 공보 2005/0021966 A1의 '지속가능한 디지털 워터마킹을 위한 방법 및 시스템(METHOD AND SYSTEM FOR SUSTAINABLE DIGITAL WATERMARKING)'; 미국 특허 공보 005/0138392 A1의 '생체 검증을 위한 안전한 방법 및 시스템(SECURE METHOD AND SYSTEM FOR BIOMETRIC VERIFICATION)'; 미국 특허 공보 2004/0268322 A1의 '컴퓨터 보호를 위한 안전한 방법 및 시스템(SECURE METHOD AND SYSTEM FOR COMPUTER PROTECTION)'; 미국 특허 공보 2005/0021989-A1의 '디지털 매체를 처리 및 배포하기 위한 안전한 방법 및 시스템(SECURE METHOD AND SYSTEM FOR HANDLING AND DISTRIBUTING DIGITAL MEDIA)'; 미국 특허 공보 2005/0166191 A1의 '소프트웨어에서 비트-단위 및 2의 보수 정수 연산들을 모호하게 하기 위한 시스템 및 방법(SYSTEM AND METHOD FOR OBSCURING BIT-WISE AND TWO'S COMPLEMENT INTEGER COMPUTATIONS IN SOFTWARE)'; 미국 특허 공보 2006/0140401-A1의 '화이트 박스 공격으로부터 컴퓨터 소프트웨어를 보호하기 위한 시스템 및 방법(SYSTEM AND METHOD FOR PROTECTING COMPUTER SOFTWARE FROM A WHITE BOX ATTACK)'; 미국 특허 공보 2004/0139340-A1의 '화이트 박스 공격으로부터 컴퓨터 소프트웨어를 보호하기 위한 시스템 및 방법(SYSTEM AND METHOD FOR PROTECTING COMPUTER SOFTWARE FROM A WHITE BOX ATTACK)'; 미국 특허 공보 003/0172293-A1의 '버퍼-오버플로 및 에일리언-코드 공격들을 미연에 방지하는 시스템 및 방법(SYSTEM AND METHOD OF FOILING BUFFER-OVERFLOW AND ALIEN-CODE ATTACKS)'; 미국 특허 공보 2005/0002532-A1의 '암호화 개인 키들을 은닉하는 시스템 및 방법(SYSTEM AND METHOD OF HIDING CRYPTOGRAPHIC PRIVATE KEYS)'; 미국 특허 제6,779,114호의 '변조에 내성을 갖는 소프트웨어-제어 흐름 부호화(TAMPER RESISTANT SOFTWARE-CONTROL FLOW ENCODING)'; 미국 특허 제6,594,761호의 '변조에 내성을 갖는 소프트웨어 부호화(TAMPER RESISTANT SOFTWARE ENCODING)'; 미국 특허 제6,842,862호의 '변조에 내성을 갖는 소프트웨어 부호화(TAMPER RESISTANT SOFTWARE ENCODING)'; 미국 특허 제7,350,085호의 '변조에 내성을 갖는 소프트웨어-대량 데이터 부호화(TAMPER RESISTANT SOFTWARE-MASS DATA ENCODING)'와 같은 특허 문헌들에서 찾아 볼 수 있으며, 이러한 특허 문헌들의 내용들 모두는 그대로 본원 명세서에 참조병합된다.

화이트-박스 데이터 생성

화이트-박스 암호화 기능에 대해 각각 고유하게 식별되는 호출은 그러한 호출에 대해 취해진 기능 및 보안-관련 선택들에 기반하여 생성되어야 하는, 연관 데이터를 지니게 된다. 이러한 데이터를 생성하는 화이트-박스 데이터 생성 도구(154)는 이하에서

(154)으로 언급된다.

상기

도구(154)는 상기 화이트-박스 라이브러리에 필요한 초기화된 테이블 데이터의 형태로, 화이트-박스 호출에 대한 인스턴스-특정 데이터의 초기화를 생성할 책임을 갖는다. 사용자의 애플리케이션의 어딘가에서 암호화 동작들에 이용되는 각각의 암호화 도메인은 그러한 테이블 데이터의 생성을 필요로 하게 된다. 상기 초기화된 데이터의 정확한 값들은 사용자의 소스-코드의 임의의 변환에 의해 생성되는 바와 같은 사용자의 암호화 데이터(평문텍스트/암호텍스트 등)의 변환들에 의존한다. 예를 들면, 서로 다른 호출들(심지어는 동일한 기능성 매개변수들을 가진 호출들)은 아마도 서로 다른 키들을 사용하며 자신들의 입력들과 출력들에 관한 서로 다른 변환들을 지닌다. 또한, 임의의 구현 선택들이 각각의 화이트-박스 호출을 위한 도구 체인에 의해 취해진다.

(154)은 이들 모두의 선택들을 캡슐화하는 구현-특정 데이터를 생성한다.

호출 동안, 이러한 데이터는 키- 및 변환-불가지론(agnostic) 화이트-박스 라이브러리 코드(

)에 전달된다.

(154)은 사용자 애플리케이션 코드 자체를 처리할 필요가 없는데, 그 이유는

(150)이 이미 상기 소스-코드를 분석했고 필요한 정보를 화이트-박스 메타데이터(176)로 작성했다고 예상되기 때문이다.

상기

도구(154)는

(150)에 의해 생성된 화이트-박스 메타데이터(176), 및 (글루 코드가 변환된 경우에) 상기 데이터 변환 엔진(152)에 의해 생성된 외부 변환, 또는 글루, 메타데이터(184)를 입력으로서 취한다. 이러한 정보는 어떤 암호화 동작들이 사용자 애플리케이션 코드에서 발견되는지, 어떤 암호화 매개변수들이 그러한 동작들에 대해 상기 화이트-박스 매개변수화 파일들에서 지정되었는지, 그리고 어떤 데이터 변환들이 실제 매개변수들로서 전달되는 사용자-데이터에 적용되었는지를

(154)에게 알려준다. 상기

도구(154)는 상기 화이트-박스 데이터를 정의하는 코드, 및 선택적으로는 엑스포트(export) 데이터 파일들(186)을 생성한다.

(154)의 출력은 상기 매개변수화 파일(124) 내의 각각의 레코드에 해당하는 데이터를 포함하는 데이터 초기화 파일(188)(

)이다. 상기 데이터 초기화 파일(188)은 각각의 화이트-박스 호출에 대한 인스턴스-특정 데이터를 캡슐화하는 한 세트의 데이터 변수들("데이터 초기화들")을 포함한다. 상기 데이터 값들은 또한 이러한 파일 내에 저장되거나, 상기 매개변수화 파일(124)에서 사용자에 의해 지정되는 하나 이상의 출력 파일들에 저장된다. 생성될 모든 데이터가 엑스포트 데이터일 경우에,

(154)은 사실상 컴파일 및 링크 다음에 실행될 수 있다.

(154)은 단일의 개발자에 의해 엠베드된 데이터(및 선택적으로는 엑스포트 데이터)를 생성하도록 실행될 수 있다. 그 시점에서, 애플리케이션을 컴파일 및 링크하고자 하는 어떤 사람은 단지 원래의 컴파일 도구들만을 필요로 한다.

상기 화이트-박스 테이블 데이터 매개변수들의 정의들은

(154)에 의해 생성되지만, 상기 글루 코드는 이러한 글루 코드가 적절한 경우에 상기 화이트-박스 라이브러리 호출들에 실제 매개변수들로서 전달되게 하여야 한다. 특히 유념할 사항은 전형적인 화이트-박스 포함 파일(170)과 관련하여 위에서 상술된 서브-포함 파일들(

등)이다. 이들은 화이트-박스 암호화 동작들의 각각의 가능한 변형에 대한 정식 매개변수들을 세부적으로 정의하고, 상기 화이트-박스 글루 파일들(172,174)에서 벌크 텍스트(bulk of text)를 생성하는데 사용된다. 이러한 서브-포함 파일들은, 또한 상기 화이트-박스 라이브러리 코드 자체를 생성하는 프로그램에 의해 자동으로 생성되는 것이 바람직하다. 이러한 방식으로, 낮은 수준의 화이트-박스 API의 정확한 형태의 종속성 대부분은 자동으로 유지된다.

(154)은 일반적으로, 추상된 화이트-박스 API들의 새로운 호출들로 애플리케이션 코드가 업데이트되는 경우마다, 또는 화이트-박스 매개변수화 파일(124)이 수정되는 경우에, 또는 애플리케이션 코드가 변환되는 경우에, 재-실행된다.

변환된 코드의 컴파일 및 링크

트랜스코딩되거나 변환된 코드를 컴파일 및 변환하기 위해, 변환된 소스 파일(180)(

), 변환된 화이트-박스 호출 정의 파일(182)(

), 및 데이터 초기화 파일(

)은, 사용자 애플리케이션 코드를 컴파일하고 오브젝트 파일(object file)(들)(192)을 생성하는데 사용되는 동일한 원래의 도구 컴파일러(190)를 사용하여 컴파일되고, 보호 실행가능 파일(198)을 생성하도록 화이트-박스 라이브러리(196)(

)에 대하여, 링커(linker; 194)(

)에 의해 링크된다. 상기 화이트-박스 라이브러리에 의해 구현되는 암호화 동작들 및 개별 서브루틴들의 정확한 API의 세부사항들이 본원 명세서의 범위를 벗어나 있다.

성능 튜닝

변환된 코드의 테스트 동안, 사용자는 애플리케이션의 성능 또는 크기에 만족하지 않음을 발견할 수 있거나, 선택적으로는 상기 성능이 허용가능한 것 이상이고, 보안이 개선될 수 있는 영역들이 있음을 알 수 있다. 이 시점에서, 이전 단계에서 취해진 기능 또는 보안성 선택들 중 어느 하나가 재이용(revisiting)될 수 있으며, 변경사항들만이 상기 매개변수화 파일(124)에 대해 이루어질 필요가 있다. 여러 매개변수는 서로 다른 크기/속도/보안성의 조절(trade-off)들을 하도록 변경될 수 있다. 예를 들면:

·암호화 타입이 높은 성능 변형, 또는 높은 보안 변형 중 하나로, 변경될 수 있다.

·(의미가 있는 경우에) 회전의 횟수는 높은 성능 및 작은 크기에 대해 줄어들 수 있거나, 높은 보안성에 대해 늘어날 수 있다.

·데이터 서플링(data shuffling)은 높은 보안에 대해 턴온될 수 있거나, 높은 성능에 대해 턴오프될 수 있다.

·서로 다른 화이트-박스 호출들이 크기를 줄이기 위해 동일한

로 주어질 수 있거나, 동일한

를 갖는 호출들이 보안성을 개선하기 위해 서로 다른 호출들로 주어질 수 있다.

·애플리케이션 코드 또는 생성된 코드가 변환되는 데이터 변환 설정들은 성능을 개선하도록 낮게 할 수 있거나, 보안성을 개선하기 위해 높게 할 수 있다. 심지어, 사용자는 생성된 코드를 전혀 변환하지 않도록 선택할 수 있다.

위에 기술된 화이트-박스 도구 체인은 사용자의 애플리케이션 내에서 안티-디버그 및 무결성 검증을 사용할 수 있는 사용자의 능력에 아무런 영향을 주지 않는다. 더욱이, 사용자는 예를 들면 사용자의 화이트-박스 호출 전후에 안티-디버그 타이밍 포인트들을 적용함으로써, 또는 상기 화이트-박스 라이브러리를 포함하는 모듈을 서명 및 무결성 검사함으로써 사용자의 화이트-박스 호출들에 대해 심층적인 방어를 추가할 수 있다.

다양한 인스턴스들의 생성

종종 보안 관점에서는 애플리케이션의 하나 이상의 인스턴스를 갖는 것이 유리하다. 애플리케이션 다이버시티( diversity )는, 사용자 기반으로 애플리케이션의 서로 다른, 하지만 기능적으로 동일한 여러 버전을 배포하거나 알려진 취약점들을 완화하거나 공격들이 일어나지 않게 하도록 필드 애플리케이션(fielded application)들을 자주 업데이트하는 것을 의미한다(이러한 종류의 "시간별 다이버시티(diversity of time)"를 수행할 수 있는 능력은 "재생성(renewability)"으로서 알려져 있다).

확실한 점으로는, 각각의 인스턴스에 대하여는 한번인 경우에, 단순히 위에 기술된 단계들을 여러 번 실행함으로써, 화이트-박스 암호화를 사용하여 애플리케이션들의 다양한 인스턴스들을 생성하는 것이 가능하다는 것이다. 그러나, 이러한 접근법은 느리기도 할 뿐더러 각각의 인스턴스가 개별적으로 테스트되어야 할 필요가 있는데, 이는 적용될 수 있는 다이버시티를 매우 제한한다. 다른 접근법은 애플리케이션 대부분이 인스턴스들 간에 동일한 것이게 하는 것이고, 그러한 다이버시티가 데이터 구동되게 하는 것인데, 이것이 의미하는 것은 애플리케이션이 이미 컴파일 및 링크된 후에 실제로 생성될 수 있다는 것을 의미한다. 데이터 기반 다이버시티는 클라이언트 상의 데이터가 업데이트될 수 있는 고정 채널(channel in place)이 종종 존재한다. 이미 빌드된 애플리케이션에 대해 다양한 데이터를 생성하는 이러한 프로세스는 "개별화(individualization)"라고 언급된다. 화이트-박스 암호화 데이터의 개별화는 애플리케이션이 빌드된 후에 엑스포트 테이블들을 사용하고

(154)을 반복해서 실행함으로써 달성될 수 있다. 이를 달성하는 한가지 방법은

(154)을 사용하여 별도의 고정 키를 애플리케이션의 각각의 인스턴스와 관련시키는 것이다.

(154)이 실행될 때마다 상기 매개변수화 파일(124)을 변경할 필요 없이 이러한 사용을 용이하게 하기 위해, 상기 고정 키가 또한 커맨드 라인 상에서 지정될 수 있다.

요약

이전의 섹센들에서, 화이트-박스 암호화 기능을 애플리케이션 내에 통합시키는데 필요한 단계들이 기술되었다. 이러한 단계들은 다음과 같이 요약될 수 있다.

ㆍ사용자가 자신의 애플리케이션에 화이트-박스 암호화 API에 대한 호출들을 추가한다.

ㆍ사용자가 화이트-박스 매개변수화 파일을 생성하고 각각의 호출에 대해 레코드들을 추가한다.

ㆍ사용자가

에 이어서

를,

에 이어서

을 실행시켜 트랜스코딩된 빌드를 위한 지원 코드 및 데이터를 생성한다.

ㆍ사용자가 자신의 애플리케이션을 컴파일, 링크 및 테스트한다.

ㆍ사용자는 자신이 크기, 성능 및 보안성에 만족할 때까지 단계들을 반복한다.

ㆍ사용자가 지원 데이터의 다양한 인스턴스들을 생성하도록 반복해서

을 실행한다.

위에 기술된 본 발명의 실시예들은 단지 예들인 것으로 의도된 것이다. 특정 실시예들은 본원 명세서에 첨부된 청구항들에 의해서만 정의되는, 발명의 범위로부터 벗어나지 않고서도 당업자에 의해 변경, 수정 및 치환될 수 있다.

Claims

화이트-박스 암호화(white-box cryptography)를 사용하여 보호 소프트웨어 애플리케이션을 생성하는 컴퓨터-구현 방법에 있어서,
애플리케이션 소스 코드 및 추상화(abstract)된 화이트-박스 기능 호출들을 포함하는 적어도 하나의 입력 소스 파일을 수신하는 단계;
각각의 추상화된 화이트-박스 기능 호출에 대해 암호화 도메인 매개변수들을 포함하는 매개변수화(parameterization) 파일을 수신하는 단계;
각각의 추상화된 화이트-박스 기능 호출의 암호화 도메인 매개변수들에 따라 각각의 추상화된 화이트-박스 기능 호출을 정의하는 화이트-박스 호출 정의 데이터를 생성하는 단계;
변환된 소스 파일 및 변환된 화이트-박스 호출 정의 데이터를 각각 생성하도록 상기 입력 소스 파일 및 상기 화이트-박스 호출 정의 데이터에 대해 적어도 하나의 데이터 변환을 적용하는 단계; 및
상기 화이트-박스 호출 정의 데이터 및 상기 변환된 화이트-박스 호출 정의 데이터에 따라 각각의 화이트-박스 기능 호출에 대해 인스턴스(instance)-특정 데이터를 포함하는 데이터 초기화들을 생성하는 단계;
를 포함하는, 컴퓨터-구현 방법.
제1항에 있어서,
상기 변환된 소스 파일, 상기 변환된 화이트-박스 정의 데이터 및 데이터 초기화 코드를 컴파일하고 결과적으로 컴파일된 코드를 화이트-박스 라이브러리에 링크시켜 실행가능 소프트웨어 애플리케이션을 제공하는 단계;
를 더 포함하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 화이트-박스 호출 정의 데이터를 생성하는 단계는 각각의 화이트-박스 기능 호출에 대해 선택되는 매개변수들을 지정하는 화이트-박스 메타데이터 및 화이트-박스 호출 정의 파일을 생성하는 단계를 포함하는, 컴퓨터-구현 방법.
제3항에 있어서, 상기 변환된 화이트-박스 호출 정의 데이터에 대해 상기 적어도 하나의 데이터 변환을 적용하는 단계는 선택 매개변수들에 대해 선택되는 데이터 변환들을 지정하는 변환 메타데이터 및 변환된 화이트-박스 호출 정의 파일을 생성하는, 컴퓨터-구현 방법.
제4항에 있어서, 상기 데이터 초기화들을 생성하는 단계는 상기 화이트-박스 메타데이터 및 상기 변환 메타데이터에 따라 데이터 초기화 파일을 생성하는 단계를 포함하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 화이트-박스 호출 정의 데이터를 생성하는 단계는,
데이터 변환 엔진에 의해 파악되는 변환 수식어(transformation qualifier)들을 포함하는 적어도 하나의 화이트-박스 호출 정의 파일을 생성하는 단계; 및
상기 선택된 변환들 및 상기 암호화 도메인 매개변수들을 기술하는 적어도 하나의 변환 메타데이터 파일을 생성하는 단계;
를 포함하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 화이트-박스 호출 정의 데이터를 생성하는 단계는, 상기 애플리케이션 소스 코드에 화이트-박스 구현 '애플리케이션 절차 인터페이스(Application Procedural Interface; API)'들을 자동 방식으로 연결시켜 주는 코드, 및 통신해야 할 때 화이트-박스 구현 API를 다른 화이트-박스 구현 API에 연결시켜 주는 코드를 생성하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 화이트-박스 기능 호출들은 적어도 하나의 연쇄된 암호화를 호출하는, 컴퓨터-구현 방법.
제8항에 있어서, 상기 적어도 하나의 연쇄된 암호화는 단일의 동작으로서 수행되는, 컴퓨터-구현 방법.
제2항에 있어서,
상기 실행가능 소프트웨어 애플리케이션의 다양한 인스턴스들을 생성하는 단계;
를 더 포함하는, 컴퓨터-구현 방법.
제10항에 있어서, 상기 다양한 인스턴스들을 생성하는 단계는 상기 실행가능 소프트웨어 애플리케이션의 각각의 인스턴스와 별도의 고정 키를 관련시키는 단계를 포함하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 적어도 하나의 데이터 변환은 블록 암호를 포함하는, 컴퓨터-구현 방법.
제1항에 있어서, 상기 적어도 하나의 데이터 변환은 비대칭 암호를 포함하는, 컴퓨터-구현 방법.
화이트-박스 암호화(white-box cryptography) 기법들을 사용하여 소프트웨어 애플리케이션을 생성하는 컴퓨터-구현 방법에 있어서,
애플리케이션 소스 코드 및 추상화(abstract)된 화이트-박스 기능 호출들을 포함하는 적어도 하나의 입력 소스 파일을 수신하는 단계;
각각의 추상화된 화이트-박스 기능 호출에 대해 암호화 도메인 매개변수들을 포함하는 매개변수화(parameterization) 파일을 수신하는 단계;
각각의 화이트-박스 기능 호출에 대해 선택되는 매개변수들을 지정하는 화이트-박스 메타데이터, 및 각각의 추상화된 화이트-박스 기능 호출의 암호화 도메인 매개변수들에 따라 각각의 추상화된 화이트-박스 기능 호출을 정의하는 화이트-박스 호출 정의 파일을 생성하는 단계;
변환된 소스 파일을 생성하도록 상기 입력 소스 파일에 대해 적어도 하나의 데이터 변환을 적용하는 단계;
선택 매개변수들에 대해 선택되는 데이터 변환들을 지정하는 변환 메타데이터 및 변환된 화이트-박스 호출 정의 파일을 생성하도록 상기 화이트-박스 호출 정의 파일에 대해 상기 적어도 하나의 데이터 변환을 적용하는 단계;
상기 화이트-박스 메타데이터 및 상기 변환 메타데이터에 따라 각각의 화이트-박스 기능 호출에 대해 인스턴스-특정 데이터를 포함하는 데이터 초기화 파일을 생성하는 단계; 및
상기 변환된 소스 파일, 상기 변환된 화이트-박스 정의 파일 및 상기 데이터 초기화 파일을 컴파일하고, 결과적으로 컴파일된 코드 파일을 화이트-박스 라이브러리에 링크시켜 실행가능 소프트웨어 애플리케이션을 제공하는 단계;
를 포함하는, 컴퓨터-구현 방법.
컴퓨터 실행가능 명령어들을 저장하는 컴퓨터-판독가능 매체를 포함하는 컴퓨터 프로그램 생성물로서, 상기 컴퓨터 실행가능 명령어들은, 프로세서에 의해 실행될 때, 상기 프로세서로 하여금, 화이트-박스 암호화(white-box cryptography)를 사용하여 보호 소프트웨어 애플리케이션을 생성하는 방법을 수행하게 하는, 컴퓨터 프로그램 생성물에 있어서,
상기 방법은,
애플리케이션 소스 코드 및 추상화(abstract)된 화이트-박스 기능 호출들을 포함하는 적어도 하나의 입력 소스 파일을 수신하는 단계;
각각의 추상화된 화이트-박스 기능 호출에 대해 암호화 도메인 매개변수들을 포함하는 매개변수화(parameterization) 파일을 수신하는 단계;
각각의 추상화된 화이트-박스 기능 호출의 암호화 도메인 매개변수들에 따라 각각의 추상화된 화이트-박스 기능 호출을 정의하는 화이트-박스 호출 정의 데이터를 생성하는 단계;
변환된 소스 파일 및 변환된 화이트-박스 호출 정의 데이터를 각각 생성하도록 상기 입력 소스 파일 및 상기 화이트-박스 호출 정의 데이터에 대해 적어도 하나의 데이터 변환을 적용하는 단계; 및
상기 화이트-박스 호출 정의 데이터 및 상기 변환된 화이트-박스 호출 정의 데이터에 따라 각각의 화이트-박스 기능 호출에 대해 인스턴스-특정 데이터를 포함하는 데이터 초기화들을 생성하는 단계;
를 포함하는, 컴퓨터 프로그램 생성물.
제15항에 있어서, 상기 방법은, 상기 변환된 소스 파일, 상기 변환된 화이트-박스 정의 데이터 및 데이터 초기화 코드를 컴파일하고, 결과적으로 컴파일된 코드를 화이트-박스 라이브러리에 링크시켜 실행가능 소프트웨어 애플리케이션을 제공하는 단계;를 더 포함하는 컴퓨터 프로그램 생성물.
제15항에 있어서, 상기 화이트-박스 호출 정의 데이터를 생성하는 단계는 각각의 화이트-박스 기능 호출에 대해 선택되는 매개변수들을 지정하는 화이트 박스-메타데이터 및 화이트-박스 호출 정의 파일을 생성하는 단계를 포함하는, 컴퓨터 프로그램 생성물.
제17항에 있어서, 상기 변환된 화이트-박스 호출 정의 데이터에 대해 상기 적어도 하나의 데이터 변환을 적용하는 단계는 선택 매개변수들에 대해 선택되는 데이터 변환들을 지정하는 변환 메타데이터 및 변환된 화이트-박스 호출 정의 파일을 생성하는, 컴퓨터 프로그램 생성물.
제18항에 있어서, 상기 데이터 초기화들을 생성하는 단계는 상기 화이트-박스 메타데이터 및 상기 변환 메타데이터에 따라 데이터 초기화 파일을 생성하는 단계를 포함하는, 컴퓨터 프로그램 생성물.
제15항에 있어서, 상기 적어도 하나의 데이터 변환은 블록 암호 또는 비대칭 암호 중 적어도 하나를 포함하는, 컴퓨터 프로그램 생성물.