KR102396071B1 - 소프트웨어 시스템의 자동화된 검증 기법 - Google Patents

소프트웨어 시스템의 자동화된 검증 기법 Download PDF

Info

Publication number
KR102396071B1
KR102396071B1 KR1020177008884A KR20177008884A KR102396071B1 KR 102396071 B1 KR102396071 B1 KR 102396071B1 KR 1020177008884 A KR1020177008884 A KR 1020177008884A KR 20177008884 A KR20177008884 A KR 20177008884A KR 102396071 B1 KR102396071 B1 KR 102396071B1
Authority
KR
South Korea
Prior art keywords
software
code
software code
assembly language
level
Prior art date
Application number
KR1020177008884A
Other languages
English (en)
Other versions
KR20170063662A (ko
Inventor
크리스 호블리첼
브라이언 파노
제이콥 알 로흐
조나단 알 하웰
브라이언 디 질
Original Assignee
마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 filed Critical 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Publication of KR20170063662A publication Critical patent/KR20170063662A/ko
Application granted granted Critical
Publication of KR102396071B1 publication Critical patent/KR102396071B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)

Abstract

소프트웨어 시스템(예를 들어, 소프트웨어 스택)의 소프트웨어 코드는 사양을 준수하는 것으로 검증될 수 있다. 소프트웨어 시스템의 하이 레벨 언어 구현은 컴파일러를 사용하여 컴파일링되어 어셈블리 언어 구현을 생성할 수 있다. 소프트웨어 시스템에 대응하는 하이 레벨 사양은 로우 레벨 사양으로 변환될 수 있다. 검증기는 어셈블리 언어 구현이 로우 레벨 사양에 설명된 속성을 기능적으로 준수하는지를 검증할 수 있다. 이 방식으로, 소프트웨어 시스템(예를 들어, 운영 체제, 디바이스 드라이버, 소프트웨어 라이브러리, 및 하나 이상의 애플리케이션을 포함하는 완전한 소프트웨어 시스템)은 로우 레벨(예를 들어, 어셈블리 언어 레벨)에서 검증될 수 있다.

Description

소프트웨어 시스템의 자동화된 검증 기법{AUTOMATED VERIFICATION OF A SOFTWARE SYSTEM}
사용자가 개인 데이터를 원격 서비스(예를 들어, 클라우드 기반 서비스)로 제출할 때, 이 개인 데이터가 안전할 것이라거나 서비스가 정확한 결과를 만들어낼 것이라는 보장이 없다. 기껏해야, 서비스는 프라이버시 정책을 가질 수 있고 데이터 유출(data breach)의 경우 서비스의 책임을 제한할 수 있다. 그러나, 최근 표제들은 운영시스템, 라이브러리, 또는 애플리케이션(예를 들어, 소프트웨어 애플리케이션)에서의 취약성이 어떻게 개인 데이터가 액세스되게 할 수 있는지의 예를 제공하였다.
본 요약은 단순화된 형식으로 개념의 선택을 도입하도록 제공되며 이하의 상세한 설명에서 추가로 설명된다. 본 요약은 청구된 청구 대상의 주요한 또는 필수적인 특징을 식별하기 위한 것이 아니고, 또는 청구된 청구 대상의 범위를 결정하거나 제한하기 위해 사용되는 것이 아니다.
일부 구현예는 소프트웨어 코드가 대응 사양(specification)을 준수하는지를 검증하는 기술을 포함할 수 있다. 소프트웨어 시스템의 하이 레벨 언어 구현은 컴파일러를 사용하여 컴파일링되어 어셈블리 언어 구현을 생성할 수 있다. 소프트웨어 시스템은 대응하는 하이 레벨 사양을 가질 수 있다. 유한 상태 머신으로서 표현되는 하이 레벨 사양은 로우 레벨 사양으로 변환될 수 있다. 어셈블리 언어 구현의 속성은 로우 레벨 사양을 준수하는 것으로서 검증될 수 있다. 이런 방식으로, 시스템의 정확성이 전체적으로(예를 들어, 완전한 소프트웨어 스택) 로우 레벨(예를 들어, 어셈블리 언어 레벨)에서 검증될 수 있다.
상세한 설명은 다음의 도면을 참조하여 설명된다. 도면에서, 참조 번호의 가장 좌측 숫자는 참조 번호가 처음 나타나는 도면을 식별한다. 다른 도면의 동일한 참조 번호는 유사하거나 동일한 아이템을 나타낸다.
도 1은 일부 구현예에 따른 사양 변환기를 포함하는 예시적인 아키텍쳐이다.
도 2는 일부 구현예에 따른 애플리케이션을 포함하는 예시적인 아키텍쳐이다.
도 3은 일부 구현예에 따른 신뢰 증분(trusted increment, TrInc) 애플리케이션을 포함하는 예시적인 아키텍쳐이다.
도 4는 일부 구현예에 따른 차등 프라이버시 애플리케이션(differential privacy application)을 포함하는 예시적인 아키텍쳐이다.
도 5는 일부 구현예에 따른 검증된 소프트웨어 시스템의 예시적인 아키텍쳐이다.
도 6은 일부 구현예에 따른 신뢰할 수 있는 컴퓨팅 베이스(trusted computing base, TCB)의 예시적인 아키텍쳐이다.
도 7은 일부 구현예에 따른 소프트웨어 코드와 연관된 속성을 결정하는 것을 포함하는 예시의 프로세스의 흐름도이다.
도 8은 일부 구현예에 따라 소프트웨어 코드의 속성이 대응하는 사양을 준수하는지를 검증하는 것을 포함하는 예시의 프로세스의 흐름도이다.
도 9는 일부 구현예에 따른 예비 검증을 수행하는 것을 포함하는 예시의 프로세스의 흐름도이다.
도 10은 검증된 소프트웨어 시스템을 포함하는 예시적인 아키텍쳐이다.
이론적으로, 서비스 소프트웨어 코드의 완전한 정식 검증은 서비스가 정식으로 지정된 보안 표준에 정확하게 매칭된다는 수학적 보장을 제공할 수 있다. 유감스럽게도, 소프트웨어 검증은 소프트웨어 코드의 신뢰성에 대한 확고한 보증을 제공할 수는 있지만, 계산 비용이 높아질 수 있어서 서비스 제공자들은 그들의 전체 시스템의 소프트웨어 검증을 수행하는 것이 불가능할 수 있다. 그 결과로, 서비스 제공자는 검증되지 않은 많은 양의 소프트웨어 코드로 둘러싸인 하이 레벨 언어로 기록된 소량의 프로그램에 대해서만 확고한 보증을 제공할 수 있을 뿐이다. 예를 들어, 검증된 전달 계층 보안 프로토콜 구현은 검증되지 않은 운영 체제 및 검증되지 않은 소프트웨어 라이브러리에 의존할 수 있다. 다른 예로서, RSA 암호시스템(cryptosystem)의 정확성에 대한 머신으로 체킹된 증거는 RSA 암호시스템, 대응 런타임 라이브러리, 및 운영 체제를 구현하는 암호 라이브러리의 정확성을 추정할 수 있다. 추가 예로서, 신뢰할 수 있는 어셈블리 코드에 의존하는 마이크로커널은 애플리케이션 레벨 시맨틱의 정확성에 대하여 주장할 수 없을 것이다. 따라서, 서비스는 서비스 소프트웨어 코드의 완전한 정식 검증을 수행하는 것이 불가능할 수 있고 따라서 서비스가 정식으로 특정된 보안 표준에 정확하게 매칭하는지에 대한 수학적 보증을 제공하는 것이 불가능할 수 있다.
본원에서 설명된 시스템 및 기술은 안전한 단 대 단(end-to-end)으로 검증되어진 애플리케이션을 생성하는데 사용될 수 있으며, 따라서 이 검증은 실행될 수 있는 모든 소프트웨어 코드("코드")를 커버할 수 있는데, 예를 들어, 검증되어진 코드는 실행될 수 있는 애플리케이션 뿐만 아니라 운영 체제, 라이브러리(런타임 라이브러리, 프로그램 라이브러리, 동적 라이브러리), 및 드라이버를 포함할 수 있다. 따라서, 일부 예에서, 하나 이상의 서버 상에서 실행하는 소프트웨어의 임의의 부분이 정확하다는 추정이 이루어질 필요가 없다. 검증을 받고 있는 코드는 코드 기록에 사용되는 임의의 하이 레벨 언어가 아니라 실행되는 어셈블리 코드이다. 검증 프로세스는 하드웨어가 정확하다고 추정할 수는 있지만, 컴파일러의 정확성 또는 코드의 런타임 실행에 관한 추정은 하지 않는다. 따라서, 검증 프로세스는 전체 시스템이 코드의 기능적으로 정확한 버전의 하이 레벨 추상 상태 머신을 구현하는 것을 실증(demonstrate)할 수 있다. 검증 프로세스는 안전한 원격 동등성(remote equivalence)을 실증할 수 있고, 예를 들어, 원격 사용자는 출력이 하이 레벨 추상 상태 머신의 출력과 구분될 수 없는 코드에 대해 안전한 채널을 설정할 수 있다.
서버 상에서 실행 중인 코드가 기능적으로 정확하다고 검증하는 것과 원격 동등성을 실증하는 것은 검증 프로세스가 전체 시스템의 동작에 대한 전체 사양 및 증거를 제공하는 것을 가능하게 할 수 있어서, 시스템(예를 들어 소프트웨어 코드 및 하드웨어)이 모든 가능한 상황에서 어떻게 동작할 것인지를 상세한다. 원격 동등성을 증명하는 것은 (i) 속성의 기능적 정확성을 증명하는 것과 (ii) 코드의 관계 속성(예를 들어, 상이한 입력으로 동일한 코드의 두 실행이 어떻게 서로 관련되는지에 관한 속성)을 증명하는 것을 포함하는, 불간섭(noninterference)의 증거를 포함할 수 있다. 또한, 원격 동등성은 신뢰할 수 있는 컴퓨팅(Trusted Computing)(예를 들어, 신뢰할 수 있는 컴퓨팅 그룹, 산업에 의한 구현을 위한 사양을 개발 및 공개하는 국제 산업 표준 그룹에 의해 특정됨)을 통해 안전한 원격 동등성을 제공하도록 강화될 수 있다. 예를 들어, 신뢰할 수 있는 플랫폼 모듈(TPM)과 같은, 안전한 하드웨어는 서버(들) 상에서 실행되고 있는 코드에게만 알려져 있는 공개 키가 개인 키에 대응한다는 것을 인증(예를 들어, 인증서(attestation)를 통해)하는데 사용될 수 있다. 원격 사용자는 코드에 대해 안전한 채널을 생성하도록 공개 키를 사용할 수 있어서, 코드의 추상 상태 머신과 직접 통신하는데 적합한 보안을 달성할 수 있다. 따라서, 완전하게 검증된 코드와 인증서를 통합하는 것은 단 대 단 보안의 매우 높은 보증을 제공할 수 있다.
본원에서 설명된 기술 및 시스템은 소프트웨어 개발자들이 종래 기술을 사용하는 것과 비교하여 보통의 개발자 노력으로 검증할 수 있는 안전한 애플리케이션을 개발하는 것을 가능하게 할 수 있다. 예를 들어, 종래 기술은 통상적으로 단일 소프트웨어 레이어를 검증하기 위해 수십 인년(person-years)이 소요될 수 있어서 종래 기술을 이용하여 완전한 소프트웨어 스택(예를 들어, 애플리케이션, 운영 체제, 드라이버 등)을 검증하는 것은 엄두도 못 낼 정도로 비싸다. 개발자 노력을 감소시키기 위해, 본원에서 설명된 기술 및 시스템은 시스템 소프트웨어의 빠르고, 자동화된, 단 대 단 소프트웨어 검증을 수행하는데 사용될 수 있다.
어셈블리 레벨에서 정확하게 코드를 검증하기 위해(예를 들어, 보통의 개발자 노력에 의해), 소프트웨어 개발자는 본원에서 설명된 두 가지 새로운 툴을 사용할 수 있다. 첫번째로, 사양 변환기는 소프트웨어 개발자가 하이 레벨 언어로 효율적으로 사양을 기록한 다음 대응하는 어셈블리 코드가 사양을 만족하는지를 검증하는 것을 가능하게 할 수 있다. 예를 들어, 사양 변환기는 하이 레벨 사양(예를 들어, 유한 상태 머신)을 로우 레벨 사양으로 변환하여 검증이 수행되는 것을 가능하게 할 수 있다. 두번째로, 하이 레벨 언어의 검증가능한 코드를 검증가능한 어셈블리 언어로 컴파일하는 컴파일러는 코드 및 대응하는 증거 모두를 하이 레벨 언어로부터 로우 레벨 어셈블리 코드(또는 머신 코드)로 변환하는데 사용될 수 있다. 이러한 컴파일러는 소프트웨어 개발자가 빠르게 하이 레벨 코드를 기록 및 체크하고 실행가능한 어셈블리 코드와 연관된 속성을 증명하는 것을 가능하게 할 수 있다. 예를 들어, 애플리케이션, 라이브러리, 드라이버 및 운영 체제를 포함하는, 전체 시스템(또는 이들의 임의의 서브세트)에 대한 소프트웨어는 검증가능한 어셈블리 코드를 포함하는 단일 프로그램으로 컴파일링될 수 있다. 전체 시스템 코드(예를 들어, 전체로서)의 정확성이 검증되어서, 전체 시스템 코드에 검증되지 않은 코드가 존재하지 않고 시스템의 다른 컴포넌트들 사이에 검증되지 않은 갭이 존재하지 않는다. 갭의 예시로서, 제 1 컴포넌트 X는 Q를 수행하는 것으로서 기술되고, 제 2 컴포넌트 Y는 Q를 수행하는 다른 컴포넌트(X)를 사용하여 R을 수행하는 것으로서 기술된다고 가정해 보자. X에서 의미하는 Q가 Y에서 의미하는 것과 다른 무언가를 나타낸다면, Y가 R을 수행한다는 Y의 보장은 유효하지 않을 수 있고, 이 때문에 갭이 생성될 수 있다. 검증 프로세스는 시스템의 둘(또는 둘 이상)의 컴포넌트들 사이에 검증되지 않은 갭이 존재하지 않음을 검증한다.
또한, 검증 프로세스는 시스템의 각각의 컴포넌트가 시스템의 다른 컴포넌트의 사양을 손상(subverting)시키는 것이 불가능함을 검증한다. 예를 들어, 애플리케이션은 운영 체제의 메모리 관리 서브시스템을 손상시키지 않도록 검증될 수 있고, 운영 체제의 메모리 관리 서브시스템은 애플리케이션을 손상시키지 않도록 검증될 수 있다.
또한, 본원에서 설명된 시스템 및 기술은 증분 검증(incremental verification), 불투명 기능(opaque function), 및 자동 요구조건 생성(automatic requirement generation)을 제공하는 검증 툴을 포함한다. 검증 툴 이외에, 비트, 바이트 및 워드의 조작 어레이를 위한 증명가능한 정확한 라이브러리, 시스템 프로그래밍에서 공통인 수학적 표현을 증명하기 위한 툴(예를 들어, 바이트에서 워드로 변환할때 값이 어떻게 증가하는지에 대한 추론), 및 예를 들어, 암호화(예를 들어, RSA OAEP(Optimal Asymmetric Encyrption Padding)), 서명(예를 들어, RSA PSS(Probabilistic Signature Scheme), 인증(예를 들어, HMAC(hash message authenitcation code)), 및 해싱(hashing)(예를 들어, SHA(Secure Hash Algorithm))과 같은 암호 작성(crypto-graphic) 동작을 위한 툴이 본원에서 설명된다.
각각이 스탠드얼론 서비스로서 유용한 여러 소프트웨어 애플리케이션이 검증가능한 소프트웨어 코드의 예로서 제공된다. 예를 들어, 객체(예를 들어, 파일, 문서 등)에 논리적 타임스탬프를 안전하게 할당하여 그 결과 이들 객체가 순서화되게 하는 공증(notary) 애플리케이션을 설명한다. 공증 애플리케이션은 점증적으로 증가하는 카운터를 포함하고, 카운터를 증분시키고, 카운터 값을 요청에 연결시키는 스테이트먼트(statement)에 서명하고(예를 들어, 서명을 사용함) 스테이트먼트 및 서명에 회신함으로써 공증화 요청에 응답하는 상태를 포함한다. 다른 세 애플리케이션은 패스워드 해셔(password hasher), 다수의 사용자에 의한 사용을 위한 신뢰할 수 있는 카운터, 및 데이터베이스의 기록을 식별하는 기회를 최소화하는 동안 데이터베이스에 대한 쿼리의 정확성을 최대화하는 차등적인 개인 데이터 베이스를 포함한다.
따라서, 자동화된 전체 시스템 검증을 통해, 어셈블리 레벨에서 외부적으로 체크가능하고, 완전하게 검증된 소프트웨어를 제공하는 기술 및 시스템이 첨부 도면과 관련하여 이하에서 설명된다. 대규모 단 대 단 검증된 시스템을 구축하기 위한 예시의 툴, 기술, 및 소프트웨어 엔지니어링 규율의 집합이 또한 설명된다. 또한, 관계 속성의 검증을 통해 어셈블리 레벨 코드의 정보 흐름 기반 보안 속성을 증명하는 예시의 접근방식 및 시스템 개발자들이 정식 검증을 위해 사용하기 위한 예시의 기술이 설명된다.
예시적인 아키텍쳐
도 1은 일부 구현예에 따른 사양 변환기를 포함하는 예시적인 아키텍쳐(100)이다. 일부 구현예에서, 아키텍쳐(100)는 원격 동등성 및 단 대 단 검증을 제공하는데 사용될 수 있다.
원격 동등성은 각 애플리케이션과 이의 대응하는 상태 머신 사이의 동등성에 관한 보장을 제공한다. 신뢰할 수 없는 네트워크를 통해 애플리케이션과 통신하는 원격 디바이스는 동일한 시퀀스의 메시지를 수신하는 것을 보증하는데 원격 디바이스가 신뢰할 수 없는 네트워크를 통해 대응하는(예를 들어, 애플리케이션에 대응하는) 상태 머신과의 통신을 수신할 것이기 때문이다. 예를 들어, 공증 애플리케이션의 사양은 공증 애플리케이션이 점증적으로 증가하는 카운터에 서명한다는 것을 나타낼 수 있다. 시스템이 이 사양에 부합한다는 것을 알고 있다면, 원격 디바이스는 예를 들어, 구동 중인 시스템이 (i) 카운터가 롤 백(roll back)하는 것을 가능하게 하지 않고, (ii) 개인 키를 공유하지 않고, (iii) 공증을 제외한 무엇이든 서명된 스테이트먼트를 제공하지 않고, (iv) 서명을 정확하게 계산하고, (v) 버퍼 오버플로우, 정수 오버플로우, 또는 다른 구현 레벨 취약점에 민감하지 않다는 보증이 제공될 수 있다.
아키텍쳐(100)는 원격 디바이스가 안전한 채널을 애플리케이션에 대해 설정하는 것을 가능하게 할 수 있다. 애플리케이션에 대해 안전한 채널을 설정하는 것은 원격 디바이스와 애플리케이션 사이의 통신과 간섭하는 신뢰할 수 없는 네트워크의 기능을 제거할 수 있다. 예를 들어, 공증 애플리케이션의 사양은 공증 애플리이션이 신뢰할 수 있는 플랫폼으로부터 랜덤(randomness)을 사용하여 키 쌍을 계산하고 개인 키의 인증서 및 신뢰할 수 있는 플랫폼으로부터의 애플리케이션의 코드를 획득한다는 것을 나타낼 수 있다. 따라서, 인증서를 수신하는 원격 디바이스는 대응하는 개인 키로 서명된 공증이 공증 애플리케이션의 코드에 의해 신뢰할 수 있는 플랫폼 상에서 생성된다는 것을 판정할 수 있어서 대응하는 개인 키로 서명된 공증은 공증 애플리케이션에 대응하는 상태 머신에 의해 생성되는 것으로서 처리될 수 있다.
보안 보증 이외에, 시스템 상에서 구동하는 임의의 소프트웨어 애플리케이션에 절대적인 신뢰가 존재하지 않는다. 따라서, 모든 소프트웨어 컴포넌트는 (i) 안전한 것으로서 검증되거나 (ii) 소프트웨어 컴포넌트가 시스템의 다른 컴포넌트의 보안에 영향을 주는 것을 방지하는 검증된 샌드박스 환경에서 실행된다.
또한, 시스템의 각 컴포넌트를 단지 독립적으로 검증하는 것 보다, 전체로서 전체 시스템이 검증될 수 있다. 이렇게 함으로써, 시스템의 보안은 시스템의 소프트웨어 컴포넌트가 어떻게 인터랙팅하는지에 관한 부정확한 가정을 피할 수 있다. 실행될 소프트웨어를 생성하는데 사용되는 컴파일러에 절대적인 신뢰가 존재하지 않는다. 따라서, 단지 명령어를 생성하기 위해 컴파일링될 하이 레벨 소스 코드 보다는 실행될 명령어(예를 들어, 어셈블리 코드)가 검증된다.
시스템을 위한 코드는 (예를 들어, 종래의 컴퓨터 언어 보다는) 검증을 지원하기 위해 설계되는 언어로 기록될 수 있다. 코드를 설계할 때, (예를 들어, 성능 보다는) 정확성의 증명을 가능하게 하는 알고리즘 및 코드 패턴이 선택되어 쉽게 검증가능한 시스템을 제공할 수 있다. 코드는 최적화가 버그를 도입할 수 있다는 우려 없이 최적화될 수 있는데, 이는 검증 툴이 최적화 기술에 의해 도입될 수 있는 임의의 에러를 포착하도록 설계되기 때문이다.
검증된 시스템은 소프트웨어 기반 공격에 대한 보안을 제공할 수 있다. 예를 들어, 상대방이 검증된 애플리케이션을 실행하기 이전 및/또는 검증된 애플리케이션을 종료한 이후 서버 상에서 소프트웨어를 실행할 수 있다. 상대방은 서버의 펌웨어, 기본 입력/출력 시스템(BIOS), 또는 주변 디바이스(예를 들어, 네트워크 카드)를 손상시킬 수 있다. 일부 경우에, 시스템은 중앙 처리 유닛(CPU), 메모리, 칩셋, 및 신뢰할 수 있는 플랫폼 모듈이 정확하게 동작하고 있다고 가정할 수 있고, 상대방이 물리적 공격(예를 들어, 전기적으로 메모리 버스에 프로빙하는 것 등)을 개시하지 않는다고 가정할 수 있다.
아키텍쳐(100)는 하이 레벨 사양(102), 사양 변환기(104), 로우 레벨 사양(106), 검증기(108), 검증 결과(110), 하이 레벨 언어 구현(112), 컴파일러(114), 어셈블리 언어 구현(116), 어셈블러(118), 및 머신 코드 구현(120)을 포함할 수 있다. 예를 들어, 사용자는 하이 레벨 사양(102) 및 하이 레벨 언어 구현(112)을 생성할 수 있다. 사양 변환기(104)는 하이 레벨 사양(102)(예를 들어, 유한 상태 머신)을 로우 레벨 사양(106)으로 변환할 수 있다.
컴파일러(112)는 하이 레벨 언어 구현(112)을 어셈블리 언어 구현(114)으로 컴파일링할 수 있다. 검증기(108)는 어셈블리 언어 구현(116)이 로우 레벨 사양(106)에 대응하는지를 검증하는 것과 같은, 다양한 기능을 자동으로(예를 들어, 사람 인터랙션 없이) 수행할 수 있다. 어셈블리 언어 구현(114)이 로우 레벨 사양(106)에 대응하는 것으로서 검증기(108)에 의해 검증된 이후에, 어셈블리 언어 구현(116)은 머신 코드 구현(116)의 형태의 실행가능한 코드로 어셈블러(118)에 의해 변환될 수 있다. 어셈블리 언어는 컴퓨터 또는 다른 프로그래밍가능한 디바이스를 위한 로우 레벨 언어의 예이고, 하드웨어 프로세서에 의해 실행되는 머신 코드 명령어와 어셈블리 언어 사이의 일 대 일 대응이 일반적으로 존재한다.
검증 스택(예를 들어, 플로이드 호어(Floyd-Hoare) 또는 유사한 추론에 기초함)은 코드의 기능적 정확성을 증명하는데 사용될 수 있다. 하이 레벨 사양(102) 및 하이 레벨 언어 구현(112)은 검증가능하게 되도록 설계되는 하이 레벨 언어를 사용하여 구현될 수 있다. 하이 레벨 언어는 내장(built-in) 사양 구성을 가질 수 있다. 검증기(108)는 하이 레벨 언어로 기록된 소프트웨어 프로그램의 기능적 정확성을 검증하는데 사용될 수 있는 정적 프로그램 검증기가 될 수 있다. 하이 레벨 언어는 프로그램의 정적 사양을 지원하도록 설계될 수 있다. 하이 레벨 언어는 명령형의, 순차적인, 지원 일반 클래스(support generic classes)가 되는 것과 같은, 다양한 피쳐를 포함할 수 있고, 동적 할당 및 유도 데이터 타입을 제공할 수 있고, 내장 사양 구성을 가질 수 있다. 하이 레벨 언어 사양은 사용자가 사전 조건, 사후 조건, 프레임 사양(판독 및 기록 세트), 및 종료 메트릭을 특정하는 것을 가능하게 할 수 있다. 하이 레벨 언어는 업데이트가능한 고스트 변수(ghost variable), 재귀 함수, 및 세트 및 시퀀스와 같은 타입을 제공할 수 있다. 사양 및 고스트 구성은 검증 동안 검증기(108)에 의해 사용될 수 있고 컴파일러(114)가 어셈블리 언어 구현(116)을 생성하고 있을 때는 컴파일러(114)에 의해 생략될 수 있다.
일부 구현예에서, 검증기(108)는 컴파일러(114)의 부분으로서 구동될 수 있다. 프로그래머는 정적 타입 체커(checker)와 유사한 방식으로 검증기(108)와 인터랙팅할 수 있고, 예를 들어, 검증기(108)가 에러를 생성할 때, 프로그래머는 하이 레벨 구현(112)에서 타입 선언, 사양, 또는 스테이트먼트 중 하나 이상을 변경함으로써 응답할 수 있다. 검증기(108)는 로우 레벨 증거 상세를 자동으로 채울 수 있다.
컴파일러(114)는 하이 레벨 사양(102)에 대응하는 하이 레벨 언어 구현(112)을 취할 수 있고 자동으로(예를 들어, 사람 인터랙션 없이) 하이 레벨 언어 구현(112)을 검증가능한 어셈블리 언어 구현(116)으로 변환할 수 있다. 어셈블리 언어 구현(116)은 SMT(Satisfiability Modulo Theories) 해결사와 같은, 추론 엔진에 의해 이행될 증거 의무를 설명하기 위한 IVL(Intermediate Verification Language)을 사용할 수 있다. IVL은 어셈블리 언어 구현(116)을 입력으로서 취하고, 증거 의무를 위한 검증 조건(VC)을 생성하고, VC를 추론 엔진으로 전달하는, 검증 엔진(예를 들어, 검증기(108))를 포함할 수 있다. 전체 시스템을 위한 코드는 검증기(108)를 사용하여 어셈블리 레벨(예를 들어, 어셈블리 언어 구현(116))에서 검증될 수 있다. 하이 레벨 언어 구현(112) 또는 컴파일러(114)의 임의의 버그는 검증기(108)에 의해 식별될 수 있다. 일부 보안 속성이 기능적 정확성을 통해 표현될 수 없기 때문에, 코드의 관계 속성을 검증하기 위한 기술이 설명되었다(예를 들어 하이 레벨 언어 구현(112)). 검증 결과(110)가 어셈블리 언어 구현(116)이 정확한 것으로서 검증되었다고 나타낼 때, 신뢰할 수 있는 어셈블러(118)는 어셈블리 언어 구현(116)을 머신 코드 구현(120)(예를 들어, 실행가능한 코드)으로 변환하는데 사용될 수 있다.
추론을 사용하여 코드 검증
검증기(108)는 추론의 타입(예를 들어, 플로이드-호러 추론 또는 다른 유사한 추론)을 사용하여 어셈블리 언어 구현(116)의 검증을 수행할 수 있다. 하이 레벨 언어 구현(112)은 프로그램이 입력할 수 있는 상태에 관한 어써션(assertions)으로 주석이 표시되고, 검증 프로세스는 프로그램에 대한 모든 가능한 입력에 대해, 프로그램이 구동 중일 때 어써션이 유효하다는 것을 증명할 수 있다. 제 1 예시로서, 다음의 프로그램은 끝에서 프로그램 상태(예를 들어, 사후 조건 상태)에 관한 어써션으로 주석이 표시되어, 출력 O이 짝수가 되어야 한다는 것을 나타낸다.
Figure 112017031724515-pct00001
제 1 예시에서, 검증기(108)는 사후 조건 "even(O)"이 모든 가능한 입력 S 및 I에 대해 참(true)을 유지한다는 것을 검증할 수 있다. 반대로, 계산 "O :=(S+S)+(I+I)"이 "O:=S+I"로 대체된다면, 일부 입력 I 및 S에 대해, 출력 O이 홀수가 될 수 있기 때문에, 검증 결과(110)는 검증이 실패했다는 것을 나타낼 수 있다.
다수의 출력을 생성하는 프로그램에 대해, 프로그램의 사양은 출력 방법에 사전 조건으로 주석을 표시함으로써 다수의 출력을 사용하여 검증될 수 있고, 이 사전 조건은 프로그램 코드가 실행되는 언제라도 참이 되어야만 한다. 제 2 예시는:
Figure 112017031724515-pct00002
제 2 예시에서, "invariant even(count)"는 신뢰될 수 있는 출력에 대해 짝수가 될 수 있다는 것을 특정한다. 어써션 "invariant even(count)"(예를 들어, 루프 불변값)은 검증기(108)가 프로그램을 검증하는 것을 가능하게 하는 정보를 제공할 수 있다. 검증기(108)는 이러한 정보(예를 들어, 루프 불변값)가 제공되지 않으면 유효 프로그램을 정확한 것으로서 자동으로 인식하지 않을 수 있다. 따라서, 검증기(108)가 어셈블리 언어 구현(116)을 검증하는 것을 가능하게 하도록, 하이 레벨 언어 구현(112)은 하나 이상의 사전조건, 사후조건, 루프 불변값, 또는 이들의 임의의 조합을 특정할 수 있다. 하이 레벨 언어 구현에서의 사전조건, 사후조건, 루프 불변값은 하이 레벨 사양(102)에 포함되는 사전조건 및 사후조건에 추가될 수 있다.
신뢰할 수 있는 사양 기록
시스템의 단 대 단 사양을 가능하게 하기 위해, 두 가지 타입의 사양, 예를 들어, 하드웨어 사양 및 소프트웨어 사양이 사용될 수 있다. 하드웨어 사양을 위해, 실행될 수 있는 각각의 어셈블리 명령어가 특정되어, 로우 레벨 검증을 가능하게 한다. 하드웨어 사양은 명령어의 예상(예를 들어, 다수의 레지스터를 합하는 ADD는 다수의 레지스터가 오버플로우를 야기하지 않는다고 가정하는 것을 예상할 수 있다) 및 시스템에 대한 명령어의 영향(예를 들어, ADD는 다수의 레지스터의 합을 목적 레지스터에 다시 기록한다)을 설명한다.
소프트웨어 사양은 대응하는 소프트웨어 애플리케이션의 원하는 동작의 추상 설명을 포함할 수 있다. 추상 설명은 로우 레벨 라이브러리 사양의 관점에서 모듈식으로 기록될 수 있다. 예를 들어, 공증 애플리케이션을 위한 소프트웨어 사양은 (i) 어떻게 공증 애플리케이션의 상태 머신이 발전하는지 그리고 (ii) 출력이 각 상태에서 허용되는지를 설명할 수 있다. 예시를 위해, 사양은 특정 상태의 하나의 출력이 RSA 서명에서 사용을 위해 정의된 서명된 메시지임을 나타낼 수 있다.
검증기(108)에 의해 수행되는 검증 프로세스는 신뢰할 수 있는 컴퓨팅 베이스(TCB)가 대응하는 하이 레벨 사양을 만족한다고 증명함으로써 TCB로부터 구현 코드를 제거할 수 있다. 그러나, 사양은 TCB의 부분이 될 수 있어서, 사양 자체는 신뢰할 수 있는 것으로서 검증되어야만한다. 따라서, 시스템의 설계는 사양으로 시작할 수 있고, 사양을 참조로써 적용하고, 관용적(idiomatic) 사양을 적용하고/거나 사양 검토를 적용할 수 있다. 따라서, 하이 레벨 사양(102)은 하이 레벨 언어 구현(112)을 시작하기 이전에 기록될 수 있다.
하이 레벨 사양(102)은 예를 들어, 사용되지 않은 특징을 특정하는 것 없이, 시스템에 의해 사용되는 이들 특징 서브세트를 특정하는 관용적 타입의 사양을 사용할 수 있다. 예를 들어, 신뢰할 수 있는 플랫폼 모듈(TPM)은 수백 페이지의 연관된 문서를 가질 수 있다. 그러나, TPM의 기능의 서브세트를 사용하는 특정 시스템은 특정 시스템에서 사용되지 않는 TPM의 기능을 특정하는 것 없이 TPM의 기능의 서브세트를 특정할 수 있다. 시스템에 의해 사용되는 기능을 포함하도록 하이 레벨 사양(102)을 기록하는 반면, 사용되지 않은 기능을 제외하는 것은 하이 레벨 사양(102)에 대해 더 작은 크기를 야기할 수 있어서(예를 들어, 사용되지 않은 기능이 포함되는 경우에 비교하여), 사람이 사양을 더 쉽고 더 정확하게 검토하는 것을 가능하게 할 수 있다.
다양한 추가적인 기술은 사양(예를 들어, 하이 레벨 사양(102))에서 버그/에러를 감소시키는데 사용될 수 있다. 예를 들어, 시스템에 의해 사용되는 기능을 포함하는 더 작은 사양은 더 쉽고 빠르게 검증될 수 있다. 다른 예로서, 구현 코드 보다 더 추상적이고, 서술적 방식으로 기록된 사양은, 사양 버그가 발생할 가능성이 적고 발생했을 때 발견하기 더 쉬울 수 있다.
검증가능한 어셈블리 언어 생성
신속한 대규모 소프트웨어 개발을 가능하게 하기 위해, 로우 레벨에서 소프트웨어 코드를 검증하는 동안, 사양 및 대응하는 어셈블리 언어가 서로에 대해 검증될 수 있다. 예를 들어, 하이 레벨 사양(102)은 로우 레벨 사양(106)으로 변환될 수 있고, 하이 레벨 언어 구현(112)은 어셈블리 언어 구현(116)으로 컴파일링될 수 있고, 검증기(108)는 어셈블리 언어 구현(116)이 로우 레벨 사양(106)에 의해 특정되는 것으로 동작한다고 검증할 수 있다. 이는 하이 레벨 언어가 컴파일러(114)를 신뢰하는 것 없이 그리고 런 타임 환경을 신뢰하는 것 없이 하이 레벨 구현(112)을 위해 사용되는 것을 가능하게 한다(예를 들어, 다양한 라이브러리, 런타임 컴포넌트, 운영 체제 유틸리티 등을 사용할 수 있음).
컴파일러(114)는 신뢰할 수 있는 컴포넌트가 될 수 있거나 될 수 없다. 예를 들어, 컴파일러(114)가 신뢰할 수 있는 컴포넌트가 아니면, 컴파일러(114)는 어셈블리 언어 구현(116)이 하이 레벨 언어 구현(112)에 대응(예를 들어, 100% 정확성을 가짐)한다는 것을 보장할 수 없을 것이다. 컴파일러(114)는 하이 레벨 언어 구현(112) 및 증거에 포함된 무엇이든 검증기(108)가 자동으로 검증하는 어셈블리 언어 구현(116)으로 변환할 수 있다. 컴파일러(114)에 의해 생성된 어셈블리 언어 구현(116)이 검증기(108)에 의해 검증되기 때문에, 컴파일러(114)는 신뢰할 수 있는 컴포넌트가 될 수 없을 것이다. 이는 소프트웨어 개발자가 보안 보증에 영향을 주는 것 없이 복잡한 특징 및 최적화를 추가하는 것을 가능하게 할 수 있다. 대신에, 검증기(108)는 컴파일러(114)에서 버그를 식별하는데 사용될 수 있다.
컴파일러(114)는 하이 레벨 언어 구현(112)을 어셈블리 언어 구현으로 변환할 때 코드 최적화를 수행할 수 있다. 예를 들어, 다음의 하이 레벨 언어 코드는 하나의 어레이를 다른 어레이로 복사할 수 있다.
Figure 112017031724515-pct00003
컴파일러(114)는 어셈블리 언어 코드가 어레이 루프 내부에서 어레이 바운드 체크를 수행하지 않기 위한 상기 어셈블리 언어 코드를 생성할 수 있는데, 불변값 0<=k<=n이 각각의 어레이로의 인덱스 k가 바운드 0 및 n 내에 존재한다는 것을 제공하기 때문이다.
소프트웨어 개발 중 예비 검증
소프트웨어 개발자를 위한 검증 부담을 줄이기 위해, 하이 레벨 사양(102) 및 하이 레벨 언어 구현(112)은 예비 검증(124)을 수행하는 소프트웨어 개발 환경(122)에서 기록될 수 있다. 예를 들어, 예비 검증(124)은 하이 레벨 언어 코드가 기록되는 것으로서 하이 레벨 사양(102)으로 하이 레벨 언어 구현(112)을 검증할 수 있다. 예시를 위해, 하이 레벨 언어 구현(112)이 검증가능한 어셈블리 언어 구현(116)으로 변환되기 이전에 하이 레벨 언어 개발 환경은 하이 레벨 사양에 대하여 하이 레벨 언어 구현(112)의 코드를 기록된 것으로서 체크할 수 있다(예를 들어, 기록되어진 이후에 즉시).
또한, 예비 검증(124)은 검증 결과 포착을 수행할 수 있어서 하이 레벨 언어 구현(112)에 대한 편집은 편집된 코드의 재검증이 될 수 있다. 소프트웨어 개발 환경(122)은 비주얼 스튜디오 IDE와 같은, 집적 개발 환경(IDE)를 포함할 수 있어서, 검증에 대한 거의 실시간 피드백을 제공할 수 있다. 개발자가 하이 레벨 언어 구현(112)을 위한 코드를 입력하고 편집함에 따라, 소프트웨어 개발 환경(122)은 에러를 식별하고 개발자가 각 에러와 연관된 상세한 에러 메시지를 보는 것을 가능하게 할 수 있다. 예를 들어, 에러 메시지를 선택하는 것은 실패한 사전조건이 강조되게 할 수 있고 사전 조건의 특정 조항을 예비 검증(124)이 불만족스럽다고 판정되게 할 수 있다. 사후 철자 체크와 연속적인 철자 체크 사이의 차이와 유사하게, 하이 레벨 언어 구현(112)이 기록된 이후에 이슈를 수정하려고 시도하기보다는, 이러한 자세한 피드백은 하이 레벨 언어 구현(112)을 위한 코드가 기록되는 동안 개발자가 반응하는 것을 가능하게 할 수 있다. 이러한 개발 환경은 개발자가 버그를 빠르게 식별하고 해결하는 것을 가능하게 할 수 있어서, 에러가 하이 레벨 언어 구현(112)의 코드를 통해 진행되기 이전에, 에러 등을 추론할 수 있다. 또한, 예비 검증(124)이 하이 레벨 언어 구현(112)을 위해 기록된 코드가 하이 레벨 사양(102)에 부합한다는 것을 증명하기 위한 정보를 개발자가 제공하라고 요청할 때 개발자가 잠재적인 문제점에 대해 경고를 받을 수 있다. 개발자는 정보, 예를 들어, 불변값의 인라인 어써션을 제공할 수 있고, 예비 검증(124)은 제공된 정보가 하이 레벨 사양(102)에 대해 검증되도록 코드가 기록되는 것을 가능하게 하는지 여부를 나타내는 즉각적인 피드백을 제공할 수 있다.
소프트웨어 개발 환경(122)은 모듈식 검증을 제공할 수 있고, 코드의 제 1 파일은 제 2 파일의 코드가 재검증되는 것 없이 코드의 이전에 검증된 제 2 파일의 인터페이스를 가져올 수 있다(import). 상호 개발자 레벨에서, 소프트웨어 개발 환경(122)은 클라우드 기반 저장 시설과 같은 공용 저장 시설을 통해 검증 결과를 공유할 수 있다. 예를 들어, 개발자는 코드를 변경하고, 검증을 구동하고, 변경된 코드를 제출할 수 있다. 다른 개발자가 코드를 체크할 때, 코드는 캐싱된 결과에 기초하여 즉시 겸증될 수 있다.
소프트웨어 개발 환경(122)은 자동 요구조건 전파를 포함할 수 있다. 예를 들어, 사용자가 하이 레벨 사양(102)을 기록하는 것은 특정 기능을 autoReq로서 지정할 수 있다. 이 지정은 소프트웨어 개발 환경(122)이 자동으로 사전 조건을 추가하여 특정 기능이 피호출자의 요구조건을 만족시키는 것을 가능하게 한다(예를 들어, 이 특정 기능이 호출하는 다른 기능).
관계 속성 검증
기능적인 정확성 이외에, 검증기(108)는 애플리케이션이 개인 키와 같은, 비밀 데이터(예를 들어, 개인용으로 유지되는 데이터 또는 제한된 액세스가 존재하는 데이터)에 관한 정보를 제공하지 않는다("유출하지 않는다")는 것을 검증할 수 있다. 비밀 데이터에 관한 누설하지 않은 정보의 속성은 불간섭으로서 지칭된다. 변수 S가 애플리케이션 내부의 비밀 데이터를 나타내고 I는 애플리케이션에 대한 공개 입력을 나타낸다고 가정한다. 이전에 논의된 바와 같이, 스테이트먼트 O :=(S+S) + (I+I)는 기능적인 정확성 사양, 예를 들어, even(O)을 만족한다. 그러나, 출력 O는 예를 들어, O/2 - I를 계산함으로써, 외부자(예를 들어, 미인증된 프로그램)가 비밀 S를 결정하는 것을 가능하게 한다. 이 예시에서, 비밀 S는 외부로 유출된다. 반대로, 스테이트먼트 O :=(S-S) + (I+I)는, even(O)를 만족하지만 출력 O에서 S에 관한 정보를 제공하지 않는데, O에 저장된 값은 I의 값에 의존하지만 S와 독립적이기 때문이다. 프로그램이 비밀 데이터에 관한 정보를 제공하지 않는다는 것을 검증하기 위해, 검증기(108)는 프로그램의 다수의 실행을 분석하고 어떤 값에 출력이 의존하는지를 판정하도록 프로그램의 실행의 출력들을 비교할 수 있다. 공개 입력 I가 프로그램의 모든 실행으로 전달되지만, 비밀 S가 프로그램의 실행들 가운데 변화된다는 것을 가정한다. 프로그램의 모든 실행이 S와 상관 없이 동일한 출력 O를 생성한다면, O는 S와 독립적이고 프로그램은 S에 관한 정보를 제공하지 않는다. 프로그램의 적어도 하나의 실행이 프로그램의 나머지 실행과 다른 출력을 생성한다면, 프로그램은 S에 관한 정보를 제공할 수 있다. 따라서, 동일한 I이지만 다른 S가 주어졌을 때 프로그램의 두 실행은 다른 O를 생성하지 않을 것임을 증명함으로써 O가 S와 독립적이라는 것을 증명하는 것이 가능하다. 수학적으로, 모든 가능한 쌍의 실행에 대해(각 쌍 L 및 R의 두 실행을 왼쪽 및 오른쪽에 대해 호출), 공개 입력 I가 동일하지만 비밀 S가 다른 경우, 출력 O는 동일할 수 있고, 예를 들어, ∀SL, SR. IL=IR=>OL>=OR이다. 스테이트먼트 O :=(S-S) + (I+I)가 조건을 만족하는 반면, O := (S+S) + (I+I)는 조건을 만족하지 않는다(예를 들어, 반례 IL=IR=1 및 SL=2 및 SR=3).
애플리케이션이 비밀 데이터를 노출시키지 않는다는 것을 결정하기 위해, 개발자는 명시적인 관계적 주석으로 코드에 주석이 표시될 수 있다. 예를 들어, xL은 left(x)로서 기록될 수 있고 xR은 right(x)로서 기록될 수 있다.
Figure 112017031724515-pct00004
이 예시에서, 관계적인 사전조건 left(I) == right(I)는 Test가 호출되는 어디든지 IL=IR 인지 여부를 검증기(108)가 판정하도록 명령하고, 관계적인 사후조건 left(O) == right(O)는 검증기(108)가 IL=IR=>OL=OR 인지 여부를 판정하도록 명령할 수 있다. 우리의 코드의 대부분에 대해, 검증기(108)는 기존의 기능적인 정확성 주석을 레버리지(levergae)시킬 수 있어서 개발자는 관계적인 주석을 제공하지 않을 것이다. 예를 들어, 검증기(108)는 코드에서 기능적인 사후조건을 사용할 수 있다:
program ComputeIpChecksum(I) returns(O) ensures O == IpChecksum(I);
IL=IR이면, IpChecksum(IL)=IpChecksum(IR)이므로, OL=OR임을 판정한다.
보안 속성 증명
프로그램의 출력이 프로그램의 비밀 데이터와 독립적임을 필요로 하는 것(및 검증하는 것)은 대부분의 실제 시스템에 대한 매우 엄격한(예를 들어, 비실제적이고 불필요한) 조건이 될 수 있다. 통상적으로, 프로그램은 출력에 서명하기 위해 비밀 키를 사용하는 것과 같이, 출력에 대한 비밀 데이터의 제한된 영향을 가능하게 할 수 있다. 이러한 프로그램을 위한 보안 정책은 서명과 같은 특정 값을 명시적으로 비밀해제(declassify)시킬 수 있어서, 서명이 출력에 포함될 수 있다.
도 2는 일부 실시예에 따른, 클라이언트, 네트워크, 애플리케이션, 및 비밀해제기를 포함하는 예시적인 아키텍쳐(200)이다. 아키텍쳐(200)는 클라이언트(202), 네트워크(204), 애플리케이션(206) 및 비밀해제기(208)를 포함하는 검증된 시스템의 구조를 도시한다. 비밀해제기(208)는 비밀 데이터로부터 도출된 선택된 출력의 해제를 승인할 수 있다. 애플리케이션의 비밀해제 정책은 애플리케이션의 사양에 의해 특정된 하이 레벨 동작에 대응하는 상태 머신으로서 표현될 수 있다. 클라이언트(202)는 네트워크(204)를 거쳐 (검증된) 애플리케이션(206)과 통신할 수 있다. 예를 들어, 클라이언트(202)는 네트워크(204)를 통해 입력 데이터 I를 송신할 수 있다. 네트워크(204)는 입력 데이터 I를 드롭(drop), 지연, 복사, 또는 맹글링(magle)시킬 수 있다. 네트워크(204)는 애플리케이션(206)의 비밀 데이터에 액세스할 수 없다. 애플리케이션(206)은 입력 데이터 I의 맹글링된 버전 I*를 수신하고 네트워크(204)를 거쳐 출력 O를 송신함으로서 응답할 수 있다. 네트워크(204)는 출력 O를 맹글링시키고 맹글링된 버전의 O*를 클라이언트에 제공할 수 있다.
출력 O를 계산할 때, 애플리케이션(206)은 비밀해제(208) 정책을 한번 이상 호출할 수 있다. 매번 비밀해제기(208)가 호출되고, 애플리케이션(206)은 비밀 데이터 S, 입력 i, 및 원하는 비밀해제된 출력 d를 비밀해제기(208)로 전달할 수 있다. 성공적인 검증을 위해, 원하는 비밀해제된 출력 d는 d=StateMachineOuput(S;i)를 특정하는 상태 머신의 비밀해제 정책에 따른 출력과 동일할 것이다. 검증기(108)가 정적 검증을 수행하고 상태 머신의 비밀해제 정책이 만족됨을 판정할 때, 비밀해제기(208)는 애플리케이션(206)이 출력 O의 부분으로서 사용할 수 있는 비밀해제된 출력 o를 생성한다.
일부 구현에서, o는 d와 동일할 수 있어서, 비밀해제기(208)는 런타임 동안 무연산(연산이 없음)이다. 그럼에도 불구하고, 비밀해제기(208)가 무연산이라는 정보는 검증기(108)에게 개시되지 않을 수 있어서, dL=dR을 개시하는 것 없이 oL=oR이 개시될 수 있다. 일부 경우에, 예를 들어, 비밀 데이터 S가 d에 대한 무제한 검색(brute-force search)를 사용하여 결정될 수 있는 곳에서(예를 들어, RSA 공개 키를 인수분해함으로써), dL=dR은 원치않는 SL=SR을 암시하는 것이다.
안전한 애플리케이션의 예시
검증된 안전한 애플리케이션(예를 들어, 아이언클래드(Ironclad) 애플리케이션으로 지칭됨)의 4개의 예시가 논의된다. 각 애플리케이션에 대한 증거는 이전에 증명된 하위 레벨 라이브러리, 드라이버 및 운영 체제에 대해 구축된다. 각 애플리케이션은 예를 들어, 사용자 데이터그램 프롤토콜(UDP)과 같은 프로토콜을 통해 다른 머신과 통신하는 스탠드얼론 시스템 이미지로 컴파일링될 수 있다. 각 예시의 애플리케이션은 데이터 센터의 적어도 하나의 전용 머신을 얻을 수 있는 유용하고 완전한 애플리케이션이다. 초미세 안전 실행 환경을 위한 하드웨어 지원은 다수의 아이언클래드 애플리케이션을 멀티플렉싱하는 것을 가능하게 할 수 있다.
공증 애플리케이션
공증 애플리케이션은 논리적 타임스탬프를 문서에 안전하게 할당하여 문서가 결과적으로 순서화될 수 있다. 종래의 시스템에서, 이러한 타임스탬프 서비스의 사용자는 머신이 정확한 소프트웨어를 실행 중이라는 것을 가정한다. 본원에서 설명된 공증 애플리케이션은 이러한 가정을 필요로 하지 않는다.
공증 원격 동등성(NOTARY REMOTE EQUIVALENCE). 공증 애플리케이션은 다음 과 같은 상태:
Figure 112017031724515-pct00005
TPM으로부터 판독된 랜덤 바이트의 제 1 연속적인 시퀀스로부터 RSA 키 생성 알고리즘을 사용하여 하나의 쌍(PublicKey,PrivateKey)이 계산됨.
Figure 112017031724515-pct00006
플랫폼 구성 레지스터(예를 들어, PCR 19)가 키 쌍의 공용 부분으로 확장되어진 TPM,
Figure 112017031724515-pct00007
0으로 초기화된 카운터 Counter,
그리고 다음과 같은 천이(transition)를 갖는 상태 머신과 동등하다.
Figure 112017031724515-pct00008
입력(connect, Nonce)이 주어지면, TPM 상태는 PCR 17 내지 19를 통해 인용값 Quote 및 외부 임시값 Nonce를 획득함으로써 변경된다. 출력은 (PublicKey;Quote).
Figure 112017031724515-pct00009
입력(notarize, Hash)이 주어지면, Counter를 증분시키고 SigPrivateKey(OP-CTR-ADV∥RFC4251Encode(Counter)∥Hash)를 리턴한다.
PCR은 보안 관련 메트릭의 안전한 저장 및 리포팅을 가능하게 하는 레지스터이다. 공증 애플리케이션을 위한 사양의 일부는 out_sig가 비밀해제되기 이전에 만족될 술어(predicate)를 포함할 수 있다(그렇지 않으면 비밀 데이터에 대한 의존성 때문에 출력될 수 없다). 이러한 술어의 단순화된 예시는:
Figure 112017031724515-pct00010
공증 동등성을 증명하는 것은 (1) 입력 불간섭, (2) 프로그램의 접속 동작의 기능적 정확성, (3) 프로그램의 공증화 동작의 기능적 정확성, 및 (4) 출력 불간섭의 증거를 포함할 수 있다. (1) 입력 불간섭 : 공증 애플리케이션이 비밀해제기(208)로 전달하는 임시값 및 메시지는 공용 데이터에 기초한다. (2) 접속의 기능적 정확성 : 애플리케이션은 정확하게 랜덤으로부터 키를 도출하고 애플리케이션이 획득하는 TPM 인용값은 PCR이 원하는 상태에 있을 때 TPM으로부터 기인한다. (3) 공증화의 기능적 정확성 : 애플리케이션은 카운터를 증분시키고 서명을 정확하게 계산한다. (4) 출력 불간섭 : 비보호된 메모리에 대한 기록은 공용 데이터 및 계산된 상태 머신 출력에만 의존한다.
TRINC 애플리케이션
도 3은 일부 구현에 따른 TrInc 애플리케이션(302)을 포함하는 예시적인 아키텍쳐(300)이다.
TrInc로서 알려져 있는, 신뢰할 수 있는 증분 애플케이션은, 공증 애플리케이션을 일반화시킨다. TrInc(302)는 사용자 마다(예를 들어, 애플리케이션 마다) 카운터를 유지하여, 각 사용자(예를 들어, 각 애플리케이션)은 사이에 갭이 존재하지 않는 연속적인 값들을 수신한다. TrInc(302)는 분산 시스템의 범용 툴이어서, TrInc(302)는 다양한 기능, 예를 들어, 변형 억제 감사 기록(tamper-resistant audit log), 비잔틴 장애 허용(Byzantine fault tolerance) 복사 상태 머신, 신뢰할 수 없는 파일 서버가 정확하게 동작하는지를 검증하는 것 등을 위해 사용될 수 있다. TrInc(302)는 카운터(306)의 생성을 가능하게 하는 생성 카운터(304) 모듈을 포함할 수 있다. 카운터(306)는 제 1 카운터(308) 부터 N번째 카운터(310)와 같은, N개의 카운터(여기서 N>0)를 포함할 수 있다. TrInc(302)는 개인 키 모듈(312), 공개 키 인증서 모듈(314), 암호화 프로세싱 모듈(316), 메타 카운터(318), 및 TrInc 상태 표시자(310)를 포함할 수 있다.
TRINC 원격 동등성. TrInc 애플리케이션(302)은 TrInc는 0으로 초기에 설정되는 메타 카운터, 각각의 튜플(Kip;vi), 및 다수의 카운터를 갖는 것을 제외하고 공증 애플리케이션과 같은 상태 머신과 원격으로 동등하다. 공증화를 대신하여 천이 TrInc은:
Figure 112017031724515-pct00011
입력(create,K)이 주어지면,
Figure 112017031724515-pct00012
i:=meta_counter로 설정하고,
Figure 112017031724515-pct00013
meta_counter를 증분시키고,
Figure 112017031724515-pct00014
(Ki,vi)=(K,0)으로 설정
Figure 112017031724515-pct00015
입력(advance;i,vnew, Msg,UserSig)이 주어지면, 카운터 튜플 i에서 vold = vi로 놓는다.
Figure 112017031724515-pct00016
vold<=vnew 이고 VerifySigKi(Vnew∥Msg, Usersig)이면, vi:=vnew로 설정하고 SigPrivateKey(OP-CTR-ADV∥encode(i)∥encode(Vold)∥encode(vnew)∥Msg).
패스워드 해싱(" PASSHASH ") 애플리케이션
패스워드 해싱 애플리케이션은 패스워드 데이터베이스의 손실을 무해하게 만들 수 있다. 예를 들어, 공격자가 데이터베이스를 훔치고 오프라인 공격을 시작할 수 있다. 데이터베이스가 적합하게 해싱되고 감춰질(salted) 때 조차도, 낮은 엔트로피 패스워드는 데이터베이스를 취약하게 만들것이다. 패스워드 해싱을 사용함으로써, 해싱된 패스워드로의 미승인된 액세스는 보안과 절충할 수 없다.
PASSHASH 원격 동등성. PASSHASH 애플리케이션은 다음의 상태 머신과 원격으로 동등하다. 상태는 TPM으로부터 판독된 제 1 32 랜덤 바이트로 초기화되는, 바이트 스트링 Secret으로 구성된다. 입력(hash, Salt, Password)이 주어지면, passhash 애플리케이션은 SHA256(Secret∥Salt∥Password)를 출력한다.
이 사양에 기초하여, 해싱된 패스워드는 오프라인 공격자에게 쓸모없는데, secret이 없이, 낮은 엔트로피 패스워드에 대한 무제한 추론 공격이 실행불가능하기 때문이다.
차등 프라이버시(" DIFFPRIV ") 서비스
도 4는 일부 구현에 따른 차등 프라이버시 애플리케이션(402)을 포함하는 예시적인 아키텍쳐(400)이다. 차등 프라이버시 애플리케이션(402)은 키 쌍(404), 하나 이상의 데이터베이스(406), 및 프라이버시 예산(budget)(408)을 포함할 수 있다.
차등 프라이버시 애플리케이션(402)은 차등 프라이버시 서비스를 제공하고 더 길고 더 복잡한 추상 사양을 갖는 더 큰 애플리케이션(예를 들어, TrInc 등과 비교하여)의 일례이다. 차등 프라이버시 애플리케이션(402)은 기여자로부터 민감한 데이터를 수집하고 분석가가 집성 데이터베이스(406)를 연구하는 것을 가능하게 할 수 있다. 차등 프라이버시 애플리케이션(402)은 각각의 기여자의 차등 프라이버시, 예를 들어, 분석가에게 제공되는 답변이 기여자의 데이터가 생략되면 제공되는 답변과 가상적으로 구별하기 어렵다는 것을 보장할 수 있다. 단일 로우만큼 다른 답변 S의 임의의 세트 및 임의의 데이터베이스 D1 및 D2의 쌍에 대해, P[A(D1)∈ S] <= λ
Figure 112017031724515-pct00017
[A(D2)∈ S]이면, 알고리즘 A는 프라이버시 ε로 차등적으로 개인화되며, 여기서 프라이버시 파라미터 λ=eε이다.
작은 프라이버시 파라미터를 갖는 다수의 쿼리는 파라미터의 곱셈을 갖는 단일 쿼리와 동등할 수 있다. 기여자에게 보장된 프라이버시 예산(408) b=λ로 시작하여, 각각의 쿼리 Q는 파라미터 λQ로 예산을 분할하는데, 즉, b':=b/λQ(예를 들어, λQ>b인 쿼리는 거절될 수 있음)이다. 노이즈 계산을 위해, 단일 데이터베이스 로우가 변화하는 경우에도 대부분의 쿼리 결과가 변화할 수 있는 것으로서, 쿼리의 민감성 △을 계산한다. 분석가는 △으로 파라미터화된 분산으로부터 도출된 랜덤 노이즈 값 및 참인 답변의 합을 수신한다. 유리수만을 포함하는 노이즈 분산이 사용될 수 있는데 노이즈 분산은 명령어 세트(예를 들어, x86 명령어 세트)를 사용하여 정확하게 샘플링될 수 있기 때문이다.
DIFFPRIV 원격 동등성. DIFFPRIV 애플리케이션은 다음의 상태를 갖는 상태 머신과 원격으로 동등하다:
Figure 112017031724515-pct00018
키 쌍 및 TPM은 공증 애플리케이션과 동등하게 초기화됨,
Figure 112017031724515-pct00019
나머지 예산 b는 실수임,
Figure 112017031724515-pct00020
로우의 시퀀스의 각각은 복사 검출 임시값 및 정수 컬럼 값의 리스트로 구성됨.
그리고 애플리케이션으로 접속하고, 데이터베이스를 초기화하고, 로우를 추가하고, 쿼리를 수행하는 천이를 포함한다.
민감성. 사양의 노이즈 계산 공식에서 민감성 파라미터로 사용되는 값 △은 쿼리 결과의 실제 민감성이 될 수 있다. 예를 들어, 우리가 A(D)를 답변으로서 정의한다면, 애플리케이션은 데이터베이스가 D일 때, 임의의 두 데이터베이스 D1 및 D2에 대해, |A(D1) - A(D2)|△를 계산한다.
검증가능성에 대해, 쿼리가 사용될 수 있고, 여기서 각각의 쿼리는 로우를 단일 값으로 변환하는 맵퍼(mapper)이고, 결과 세트를 집성하는 감소기(reducer)이고, 감소기만이 민감성에 영향을 준다. 분석가는 임의의 맵퍼를 제공할 수 있고, DiffPriv는 단일 감소기 합에 대해 민감성 속성을 제공할 수 있다. DiffPriv 애플리케이션은 RowMin 및 RowMax 파라미터를 취할 수 있고, 각각의 맵퍼가 출력 값을 하나의 범위로 클립핑(clipping)할 수 있다. 예를 들어:
Figure 112017031724515-pct00021
DiffPriv 애플리케이션은 노이즈 생성에서 사용되는 △와 감소기 출력 민감성을 관련시키는 술어를 만족시키도록 검증된다.
전체 시스템 검증
도 5는 일부 구현예에 따른 검증된 소프트웨어 시스템(500)의 예시적인 아키텍쳐이다. 소프트웨어 시스템(500)은 하나 이상의 애플리케이션(502), 하나 이상의 공통 애플리케이션 라이브러리(504), 사용자 데이터그램 프로토콜/인터넷(UDP/IP)(508) 프로토콜 모듈, 이더넷(510) 프롤토콜 모듈, 네트워크 드라이버(512), 하나 이상의 데이터 타입(514), 안전한 해시(SHA)(516) 모듈, 신뢰할 수 있는 플랫폼 모듈(TPM) 드라이버(518), RSA(520) 라이브러리, BigNum 라이브러리(522)(예를 들어, 암호화 기능을 수행하는데 사용됨), CoreMath 라이브러리(524)(예를 들어, 과학적이고, 공학적인 또는 컴퓨팅 집약적 계산(compute-intensive calculation)을 수행), 및 운영 체제(526)(예를 들어, 검증된 마이크로커널)을 포함한다. 애플리케이션(502)은 검증된(예를 들어, 샌드박스) 환경(532)에서 실행 중인 검증된 애플리케이션(528) 및 검증되지 않은 애플리케이션(530)을 포함할 수 있다.
애플리케이션(502)은 PassHash, Notary(공증), TrInc, DiffPriv, 다른 애플리케이션 또는 이들의 임의의 조합을 포함할 수 있다. 운영 체제(526)은 레이트 런칭(late launch), IOMMU, 세그먼트화(segmentation), 페이지 테이블, 다른 운영 체제 유틸리티, 또는 이들의 조합을 위한 지원을 포함할 수 있다. 소프트웨어 코드는 루프 불변값(loop invariants), 사전조건, 및 사후조건과 같은, 주석을 포함할 수 있어서 소프트웨어 코드의 검증을 가능하게 할 수 있다. 주석은 하이 레벨 정리(theorems)로 구축되는 보조 정리(lemma)로 볼 수 있다.
시스템(500)의 단 대 단 검증을 위한 단계를 예시하기 위해, 다수의 명제가 설명된다. 이들 명제는 이해를 쉽게하기 위해 이하에서 평이한 영어로 간단하게 서술된다. 실제 명제는 하이 레벨 언어 구현(112)으로 주석의 형태를 취할 수 있음을 이해할 수 있다. 이하에서 설명되는 명제는 시스템(500)을 검증할 때 사용될 수 있는 다수의 주요한 명제이다.
IOMMU 구성. 검증된 애플리케이션(예를 들어, 아이언클래드 애플리케이션)은 입력 출력 메모리 관리 유닛(IOMMU)을 구성하여 메모리를 디바이스 액세스가능하고 애플리케이션 배타적인 개인용 메모리로 분할하여 비 디바이스 동작이 애플리케이션 배타적인 개인용 메모리에 액세스한다. 어셈블리 언어 명령 사양은 비 디바이스 메모리 동작이 애플리케이션 배타적인 개인용 메모리에만 액세스하여 하드웨어의 디바이스 배타 벡터, 단순한 IOMMU에 의해 보호된다는 것을 판정하는데 사용될 수 있다.
일부 중앙 프로세싱 유닛(CPU)은 레이트 런칭으로서 또한 알려져 있는, DRTM(dynamic root-of trust for measurement)과 같은 특징을 제공할 수 있다. DRTM은 CPU를 알려진 상태로 리셋하고, 명령어의 논증(argument)에 의해 포인팅된 인메모리(in-memory) 코드의 측정치(예를 들어, 해시 코드)를 저장하고, 이 코드로 점프할 수 있다. 레이트 런칭 이후에, 하드웨어는 64 킬로바이트(KB)의 보호된 메모리와 함께 CPU의 소프트웨어 프로그램 제어를 제공할 수 있다. 64KB 이상을 사용하기 위해, 소프트웨어 프로그램은 먼저 IOMMU의 구성과 연관된 사양에 기초하여, IOMMU의 보호를 확장할 수 있다. IOMMU의 보호를 확장한 이후에, 프로그램은 64KB 영역 외부의 메모리에 액세스하는 어셈블리 언어 명령어를 위한 사전조건을 만족시킬 수 있다.
디바이스가 비밀 데이터를 볼 수 없음, 예를 들어, 비밀이 아닌 데이터만이 디바이스로 전달될 수 있다. 어셈블리 언어 명령어 사양은 데이터를 디바이스 액세스가능한 메모리, 즉, IOMMU가 디바이스로 하여금 액세스 할 수 있게 하는 메모리에 저장하는 것이 비밀이 아닌 데이터 O(예를 들어, OL = OR)만을 저장할 수 있음을 나타낼 수 있다. 더 구체적으로, 좌측 및 우측 실행은 동일한 시퀀스의 디바이스 저장을 생성할 수 있다 : 동일한 어드레스에 대한 동일한 값, 모듈로 타이밍 및 활성. 비공식적으로, 생존성(liveness)은 시스템 또는 알고리즘에서 "좋은 일은 결국은 일어난다"(즉, 시스템이 "진행한다")는 필요조건이다. 데이터베이스의 궁극적인 일관성은 생존성 특성의 일례이다.
OL = OR을 증명하기 위해, 구현 코드의 입력 경로 및 출력 경로가 관계적인 주석으로 주석이 표시될 수 있다. 입력 경로 및 출력 경로는 애플리케이션 이벤트 루프 및 네트워킹 스택을 포함할 수 있다. 예를 들어, 이더넷, 인터넷 프로토콜(IP), 및 UPD 레이어는 패킷 상의 관계 속성을 유지할 수 있다.
TPM의 키. 애플리케이션은 공개 키를 TPM의 PCR(예를 들어, PCR 19)로 정확하게 확장시킬 수 있다. 공개 키는 TPM 랜덤을 사용하여 생성될 수 있고 플랫폼을 절대 떠나지 않는다.
인증서. 애플리케이션은 이들의 공개 키를 PCR로 확장시킨 이후에 정확한 TPM 인증서를 생성할 수 있다.
귀결 2 - 안전한 채널. 클라이언트가 공개 키 및 인증서를 수신하면, 인증된 PCR 코드 값(예를 들어, PCR 17, PCR 18)은 검증된 애플리케이션의 것과 일치하고, 인증된 PCR 데이터 값(예를 들어, PCR 19)은 공개 키와 일치하고, 증명서는 인증서가 합법적인 하드웨어 TPM 제조사로부터임을 보여주고, 클라이언트는 공용키를 사용하여 안전한 채널을 검증된 애플리케이션에 직접 설정할 수 있다.
암호화 라이브러리
해싱. SHA(514)는 다양한 표준(예를 들어, FIPS 180-4 및 FIPS 198-1)을 준수할 수 있다.
RSA 동작. RSA(518)는 TPM으로부터 연속적인 랜덤을 사용하여 RSA 키를 생성하고(예를 들어, 선택적으로 샘플링되지 않음), 소수성 테스트(예를 들어, 밀러-라빈 소수성 또는 유사성 테스트)를 통과할 수 있다. RSA(518)는 패딩을 포함하는, RSA 암호화, RSA 복호화, RSA 서명 및 RSA 검증을 포함할 수 있고, 표준(예를 들어, PKCS 1.5 및 RSA 표준)을 준수하는 바이트 어레이를 생성할 수 있다.
해시 기능과 같은, 일부 타입의 암호화 원시요소(primitives)에 대해, 검증기(108)는 기능적 정확성을 검증할 수 있다. RFC 2313으로부터 도출된 RSA 사양은, 암호화 및 서명 동작을 이상적인 정수로 이루어진 키에 대한 모듈러 지수화(exponentiation)로서 정의한다. 키 생성 사양은 두 랜덤 소수로부터 도출되는 키를 사용할 수 있다. BigNum(520) 라이브러리는 암호화 원시요소를 구현하는데 사용될 수 있다. BigNum(520) 라이브러리는 32 비트 워드의 어레이를 사용하여 임의 정도 정수(arbitrary-precision integers)를 구현하고, RSA 등을 위해 사용되는 나눗셈 및 모듈로와 같은 동작을 제공할 수 있다. BigNum(520) 라이브러리는 차등 프라이버시를 위해 사용될 수 있는 유리수에 제공되는 동작을 확장하는 BigRat을 포함할 수 있다.
BIGNUM/BIGRAT 정확성. 각각의 BigNum/BigRat 동작은 정확한 무한 정도 정수(infinite-precision integer) 또는 실수를 나타내는 값을 생성할 수 있다.
일부 구현예에서, 컴파일러(114)는 신뢰할 수 있는 컴퓨팅 베이스(TCB)에 포함될 수 있다. 컴파일러(114)가 TCB의 부분이 아니라면, 어셈블리 언어 구현(116)은 검증기(108)에 의해 검증될 수 있다. 검증기(108)는 타입 안전, 어레이 바운드 안전, 및 이행성(transitive) 스택 안전과 같은, 컴파일러(114)에 의해 생성되는 다수의 불변값을 사용할 수 있다.
타입 안전. 모든 값 및 힙(heap) 객체의 콘텐츠는 하이 레벨 언어에 의해 사용되는 타입 시스템에 따른 예상되는 콘텐츠를 정확하게 나타내도록 검증될 수 있어서, 모든 값 및 힙 객체에 대한 동작은 런타임 타입 에러를 야기하지 않는다.
어레이 바운드 안전. 어레이 동작은 어레이의 바운드 내에 존재하는 인덱스를 사용할 수 있다.
이행성 스택 안전. 특정 프로그램이 호출될 때, 스택은 특정 프로그램 및 특정 프로그램이 호출할 수 있는 임의의 추가적인 프로그램에 의해 호출되는 스택 동작에 대해 충분히 남아있는 스택 공간을 가질 수 있다. 스택은 프로그램에 관한 정보를 저장하는 데이터 구조를 포함할 수 있다. 예를 들어, 프로그램이 서브프로그램(예를 들어, 서브루틴)을 호출할 때, 프로그램의 스냅샷이 서브프로그램이 호출되기 바로 직전에 스택에 저장될 수 있다. 예를 들어, 스냅샷은 프로그램 등에 의해 사용되는 변수의 값을 포함할 수 있다. 서브프로그램이 완전하게 실행될 때, 프로그램의 상태가 스택에 저장된 스냅샷을 사용하여 복구될 수 있어서 프로그램의 실행을 재개할 수 있다.
하이 레벨 언어가 타입 안전 언어(type-safe language)일 경우에도, 검증기(108)는 컴파일러(114)가 타입 안전을 보호한다고 가정하지 않을 것이다. 따라서, 검증기(108)는 하이 레벨 언어 값을 나타내는 데이터 구조를 위한 타입 불변값을 설정함으로써 어셈블리 언어 레벨에서 타입 안전을 검증할 수 있다. 예를 들어, 데이터 구조의 포인터는 예상되는 타입의 값을 포인팅할 수 있고, 임의 정수는 포인터로서 사용될 수 없다. 이러한 타입 불변값은 어셈블리 언어 코드 전반에서 유지될 수 있고 루프 불변값, 사전조건, 사후조건, 또는 이들의 임의의 조합으로 표현될 수 있다. 따라서, 외부 어셈블리 언어 타입 체커는 컴파일링된 어셈블리 언어 구현(116)을 체크하는데 사용될 수 없다. 대신에, 단일 검증 프로세스(예를 들어, 검증기(108)에 의해 수행됨)은 수동으로 기록된 어셈블리 언어 코드 및 컴파일링된 코드(예를 들어, 어셈블리 언어 구현(116)) 모두에 대해 사용될 수 있다.
하이 레벨 속성 보호. 모든 프로그램은 출력 스택 상태 및 레지스터가 하이 레벨 언어 사후조건 및 주어진 하이 레벨 언어 사전조건을 만족한다는 것을 증명한다. 컴파일러(114)는 사전조건, 사후조건 및 루프 불변값과 같은, 하이 레벨 언어 주석을 유지할 수 있다. 또한, 컴파일러(114)는 하이 레벨 주석을 로우 레벨 스택 및 레지스터 값에 연결시킬 수 있어서 스택 및 레지스터 값에 대한 동작은 하이 레벨 언어 구현(112) 및 대응하는 하이 레벨 사양(102)과 연관된 정확한 정리를 만족시킨다.
운영 체제 불변값. 운영 체제 데이터 구조 불변값이 유지될 수 있다.
가비지 콜렉션 정확성(GARBAGE COLLECTION CORRECTNESS). 운영 체제(526)의 메모리 관리자는 하이 레벨 언어의 시맨틱을 준수하는 하이 레벨 언어의 객체의 표현을 생성할 수 있다. 운영 체제(526)의 가비지 콜렉터는 정확한 객체 데이터를 유지할 수 있고, 가비지 콜렉터가 메모리 주변의 객체를 이동시킬 때에도, 허상 포인트(dangling pointer)를 떠나지 않을 것이다. 가비지 콜렉터는 메모리에 저장된 가비지, 예를 들어, 더이상 사용하지 않지만 할당되어진 메모리의 객체를 재생시킬 수 있다. 예를 들어, 시스템이 메모리의 할당된 부분에 포인팅하는 임의의 포인터를 갖지 않는다면, 메모리의 할당된 부분은 다른 프로그램에 의한 사용을 위해 가비지 콜렉터에 의해 재생될 수 있다.
도 6은 일부 구현예에 따른 신뢰할 수 있는 컴퓨팅 베이스(TCB)(602)를 포함하는 예시적인 아키텍쳐(600)이다. TCB(602)의 다양한 컴포넌트를 위한 사양은 서비스 사양(604), 하나 이상의 드라이버 사양(606), 하나 이상의 라이브러리 사양(608), 운영 체제 사양, 및 하드웨어 사양(612), 또는 이들의 임의의 조합을 포함할 수 있다. 서비스 사양(604)은 입력/출력 동작, 통신 유틸리티, 파일 시스템 조작 유틸리티, 리소스 할당 유틸리티 등과 같은, TCB(602)에 의해 제공되는 서비스를 위한 사양을 제공할 수 있다. 드라이버 사양(606)은 TCB(602)에 의해 제공되는 다양한 드라이버의 기능을 특정할 수 있다. 라이브러리 사양(608)은 TCB(602)에 의해 제공되는, 런타임 라이브러리와 같은, 다양한 라이브러리의 기능을 특정할 수 있다. 운영 체제 사양(610)은 TCB(602)에 의해 제공되는 운영 체제과 연관된 동작을 특정할 수 있다. 하드웨어 사양(612)은 하드웨어의 동작에 관한 정보를 제공할 수 있다.
검증기(예를 들어, 도 1의 검증기(108))는 소프트웨어 코드가 사양(604, 606, 608, 610 및 612)을 준수한다는 것을 검증하는 증거를 사용할 수 있다. 예를 들어, 검증기는 서비스 코드 및 증거(614)가 서비스 사양(604)을 준수하고, 드라이버 코드 및 증거(616)는 드라이버 사양(606)을 준수하고, 라이브러리 코드 및 증거(618)는 라이브러리 사양(608)을 준수하고, 마이크로 커널(예를 들어, 운영 체제) 코드 및 증거(620)는 운영 체제 사양(610)을 준수하고, 신뢰할 수 있는 하드웨어는 하드웨어 사양(612)을 준수한다는 것을 검증할 수 있다.
예시 프로세스
도 7, 8 및 9의 흐름도에서, 각 블록은 하드웨어, 소프트웨어, 또는 이들의 조합으로 구현될 수 있는 하나 이상의 동작을 나타낸다. 소프트웨어의 문맥에서, 블록은 하나 이상의 프로세서에 의해 실행 될 때, 프로세서로 하여금, 언급된 동작을 수행하게 하는 컴퓨터 실행가능한 명령어를 나타낸다. 일반적으로, 컴퓨터 실행가능한 명령어는 루틴, 프로그램, 객체, 모듈, 컴포넌트, 데이터 구조 등을 포함하여 특정 기능을 수행하거나 특정 추상 데이터 타입을 구현한다. 블록이 설명되는 순서는 제한으로서 해석되는 것이 아니고, 임의의 수의 설명된 동작은 프로세스를 구현하기 위해 임의의 순서로 및/또는 병렬로 조합될 수 있다. 논의의 목적을 위해, 프로세스(700, 800 및 900)은 위에서 설명된 바와 같은 아키텍쳐(100, 200, 300, 400, 또는 500)와 관련하여 설명되었지만, 다른 모델, 프레임워크, 시스템 및 환경이 이들 프로세스를 구현할 수 있다.
도 7은 일부 구현예에 따른 소프트웨어 코드와 연관된 속성을 결정하는 것을 포함하는 예시의 프로세스(700)의 흐름도이다. 프로세스(700)는 도 1의 소프트웨어 개발 환경(122)과 같은, 소프트웨어 개발 환경의 하나 이상의 컴포넌트에 의해 수행될 수 있다.
(702)에서, 소프트웨어 코드의 속성을 특정하는 사양이 생성될 수 있다. 예를 들어, 도 1에서, 하이 레벨 사양(102)은 하이 레벨 언어 구현(112)이 동작하는 방법과 같은 하이 레벨 언어 구현(112)의 속성을 특정할 수 있다.
(704)에서, 소프트웨어 코드의 속성은 사양을 준수하는 것으로서 검증될 수 있다. (706)에서, 소프트웨어 코드가 대응하는 사양을 준수하는 것으로서 검증되었다는 표시가 제공될 수 있다. 예를 들어, 도 1에서, 검증기(108)는 어셈블리 언어 구현(116)이 로우 레벨 사양(106)을 준수한다는 것을 검증할 수 있다. 예시를 위해, 검증기(108)는 유한 상태 머신(예를 들어, 로우 레벨 사양(106))의 동작을 어셈블리 언어 구현(116)의 동작과 비교할 수 있고, 입력 X가 주어질 때, 유한 상태 머신 및 어셈블리 언어 구현(116)이 동일한 상태에 진입하는지 여부를 판정할 수 있다. 입력 X가 주어진 이후에, 검증기(108)가 유한 상태 머신 및 어셈블리 언어 구현(116)이 동일한 상태에 진입한다고 판정하면, 검증기(108)는 어셈블리 언어 구현(116)이 검증을 통과한다는 것을 나타낼 수 있다. 입력 X가 주어진 이후에 검증기(108)가 유한 상태 머신 및 어셈블리 언어 구현(116)이 다른 상태로 진입한다고 판정하면, 검증기(108)는 검증이 실패했다는 것을 나타낼 수 있다.
따라서, 검증기는 어셈블리 언어 코드가 유한 상태 머신과 같은 로우 레벨 사양을 준수하는지 여부를 판정하는 검증을 수행할 수 있다.
도 8은 일부 구현예에 따라 소프트웨어 코드의 속성이 대응하는 사양을 준수한다고 검증하는 것을 포함하는 예시의 프로세스의 흐름도이다. 프로세스(800)는 도 1의 소프트웨어 개발 환경(122)과 같은, 소프트웨어 개발 환경의 하나 이상의 컴포넌트에 의해 수행될 수 있다.
(802)에서, 하이 레벨 언어 구현이 하이 레벨 언어 사양을 준수하는지를 검증하는 예비 검증이 수행될 수 있다. 예를 들어, 도 1에서, 예비 검증(124)은 하이 레벨 언어 구현(112)의 코드가 하이 레벨 사양(102)에 대해 기록되고 있는 것(예를 들어, 기록된 이후에 즉시)인지를 예를 들어, 하이 레벨 언어 구현(112)이 검증가능한 어셈블리 언어 구현(116)으로 변환되기 이전에, 체크할 수 있다.
(804)에서, 하이 레벨 언어 구현은 어셈블리 언어 구현을 생성하도록 컴파일링될 수 있다. 예를 들어, 도 1에서, 컴파일러(114)는 하이 레벨 언어 구현(112)을 컴파일링함으로써 어셈블리 언어 구현(116)을 생성할 수 있다. 하이 레벨 언어 구현(112)은 단일 애플리케이션, 둘 이상의 애플리케이션 또는 전체 소프트웨어 시스템(예를 들어, 애플리케이션, 드라이버, 라이브러리, 운영 체제 등)이 될 수 있다.
(806)에서, 하이 레벨 사양은 로우 레벨 사양으로 변환될 수 있다. 예를 들어, 도 1에서, 하이 레벨 사양(102)은 사양 변환기(104)에 의해 변환되어 로우 레벨 사양(106)을 생성할 수 있다. 로우 레벨 사양(106)은 동작이 하이 레벨 사양(102)에 기초하는 적어도 하나의 유한 상태 머신을 포함할 수 있다.
(808)에서, 어셈블리 언어 구현의 속성은 로우 레벨 사양을 준수하는지 검증될 수 있다. 예를 들어, 도 1에서, 검증기(108)는 어셈블리 언어 구현(116)이 로우 레벨 사양(106)을 준수하는지 검증할 수 있다. 예시를 위해, 검증기(108)는 유한 상태 머신(예를 들어 로우 레벨 사양(106))의 동작을 어셈블리 언어 구현(116)의 동작과 비교할 수 있고, 특정 입력이 주어졌을 때, 유한 상태 머신 및 어셈블리 언어 구현(116) 모두가 동일한 상태에 진입하는지 여부를 판정할 수 있다. 검증기(108)가 유한 상태 머신 및 어셈블리 언어 구현(116)이 동일한 상태에 진입한다고 판정한다면, 검증기(108)는 어셈블리 언어 구현(116)이 검증을 통과했다고 나타낼 수 있다. 검증기(108)가 유한 상태 머신 및 어셈블리 언어 구현(116)이 다른 상태에 진입한다고 판정하면, 검증기(108)는 검증이 실패했다는 것을 나타낼 수 있다.
(810)에서, 어셈블리 언어 구현에 기초한 머신 코드 구현은 어셈블러를 사용하여 생성될 수 있다. 예를 들어, 도 1에서, 어셈블러(118)는 어셈블리 언어 구현(116)에 기초하여 머신 코드 구현(120)을 생성할 수 있다.
따라서, 하이 레벨 언어 개발 환경은 다양한 툴을 제공할 수 있다. 예를 들어, 하이 레벨 언어 구현 및 하이 레벨 언어 사양은 실질적으로 동시에 특정될 수 있고 예비 검증은 하이 레벨 구현이 하이 레벨 언어 사양을 준수하다는 것을 검증하도록 수행될 수 있다. 하이 레벨 사양은 유한 상태 머신과 같은 로우 레벨 사양으로 변환될 수 있고, 하이 레벨 언어 구현은 어셈블리 언어 구현으로 컴파일링될 수 있다. 검증기는 어셈블리 언어 구현의 동작이 로우 레벨 사양을 준수한다는 것을 검증할 수 있다. 이렇게 함으로써, 애플리케이션, 라이브러리, 드라이버, 운영 체제 등을 포함하는 전체 소프트웨어 시스템은 소프트웨어 시스템의 하이 레벨 사양에 따라 수행하도록 검증될 수 있다.
도 9는 일부 구현예에 따른 예비 검증을 수행하는 것을 포함하는 예시의 프로세스의 흐름도이다. 프로세스(900)는 도 1의 소프트웨어 개발 환경(122)과 같은 소프트웨어 개발 환경의 하나 이상의 컴포넌트에 의해 수행될 수 있다.
예시의 컴퓨팅 디바이스 및 환경
도 10은 본원에서 설명된 모듈 및 기능을 구현하는데 사용될 수 있는 컴퓨팅 디바이스(100) 및 환경의 예시의 구현을 도시한다. 컴퓨팅 디바이스(100)는 예를 들어, 시스템 버스(1014) 또는 다른 적합한 연결을 통해 서로 통신하는 것이 가능한, 적어도 하나의 프로세서(1002), 메모리(1004), 통신 인터페이스(1006), 디스플레이 디바이스(1008), 다른 입력/출력(I/O) 디바이스(1010), 및 하나 이상의 대용량 저장 디바이스(1012)를 포함할 수 있다.
프로세서(1002)는 단일 또는 다중 컴퓨팅 유닛 또는 다중 코어를 포함할 수 있는 단일 프로세싱 유닛 또는 다수의 프로세싱 유닛이 될 수 있다. 프로세서(1002)는 하나 이상의 마이크로프로세서, 마이크로컴퓨터, 마이크로컨트롤러, 디지털 신호 프로세서, 중앙 프로세싱 유닛, 상태 머신, 로직 회로망 및/또는 동작 명령어에 기초하여 신호를 조작하는 임의의 디바이스로서 구현될 수 있다. 다른 기능들 중에, 프로세서(1002)는 메모리(1004), 대용량 저장 디바이스(1012), 또는 다른 컴퓨터 판독가능 매체에 저장된 컴퓨터 판독가능 명령어를 페치 및 실행시키도록 구성될 수 있다.
메모리(1004) 및 대용량 저장 디바이스(1012)는 위에서 설명된 다양한 기능을 수행하도록 프로세서(1002)에 의해 수행되는 명령어를 저장하기 위한 컴퓨터 저장 매체의 예시이다. 예를 들어, 메모리(1004)는 일반적으로 휘발성 메모리 및 비휘발성 메모리(예를 들어, RAM, ROM 등)을 포함할 수 있다. 또한, 대용량 저장 디바이스(1012)는 일반적으로, 하드 디스크 드라이브, 솔리드 스테이트 드라이브, 외부의 제거가능한 드라이브를 포함하는 제거가능한 매체, 메모리 카드, 플래쉬 메모리, 플로피 디스크, 광학 디스크(예를 들어, CD, DVD), 저장 어레이, 네트워크 부착 저장부, 저장 영역 네트워크 등을 포함할 수 있다. 메모리(1004) 및 대용량 저장 디바이스(1012) 모두는 본원에서 메모리 또는 컴퓨터 저장 매체로서 집합적으로 지칭될 수 있고, 본원의 구현예에서 설명된 동작 및 기능을 수행하도록 구성되는 특정 머신으로서 프로세서(1002)에 의해 실행될 수 있는 컴퓨터 프로그램 코드로서컴퓨터 판독가능한, 프로세서 실행가능한 프로그램 명령어를 저장하는 것이 가능한 비일시적인 매체가 될 수 있다.
컴퓨팅 디바이스(1000)는 위에서 논의된 바와 같이, 예를 들어, 네트워크, 직접 접속 등을 통해, 다른 디바이스와 데이터를 교환하기 위한 하나 이상의 통신 인터페이스(1006)를 또한 포함할 수 있다. 통신 인터페이스(1006)는 유선 네트워크(예를 들어, LAN, 케이블 등) 및 무선 네트워크(예를 들어, WLAN, 셀룰러, 위성 등)를 포함하는, 다양한 네트워크 및 프로토콜 타입 내에서 통신을 가능하게 할 수 있다. 통신 인터페이스(1006)는 또한 저장 어레이, 네트워크 부착 저장부, 저장 영역 네트워크 등에서와 같은, 외부 저장부(도시되지 않음)와의 통신을 제공할 수 있다.
모니터와 같은, 디스플레이 디바이스(1008)는 정보 및 이미지를 사용자에게 디스플레이하기 위한 일부 구현예에 포함될 수 있다. 다른 I/O 디바이스(1010)는 사용자로부터 다양한 입력을 수신하고 다양한 출력을 사용자에게 제공하는 디바이스가 될 수 있고, 키보드, 리모트 콘트롤러, 마우스, 프린터, 오디오 입력/출력 디바이스 등을 포함할 수 있다.
메모리(1004)는 검증된 소프트웨어 시스템을 생성하는데 사용될 수 있는 모듈 및 소프트웨어 컴포넌트를 포함할 수 있다. 예를 들어, 검증되어진 소프트웨어 시스템에서, 메모리(1004)는 애플리케이션(502), 공통 애플리케이션(504), UDP/IP(508), 이더넷(510), 네트워크 드라이버(512), 데이터 타입(514), SHA(516), TPM 드라이버(518), RSA(520), BigNum(522), CoreMath(524), 및 운영 체제(526)을 포함할 수 있다. 소프트웨어 개발 시스템에서, 메모리(1004)는 또한, 도 1로부터, 하이 레벨 사양(102), 사양 변환기(104), 로우 레벨 사양(106), 검증기(108), 검증 결과(110), 하이 레벨 사양(112), 컴파일러(114), 어셈블리 언어 구현(116), 어셈블러(118), 및 머신 코드 구현(120)을 포함할 수 있다.
본원에서 설명된 예시의 시스템 및 컴퓨팅 디바이스는 단지 일부 구현예에 적합한 예시이고, 본원에서 설명된 프로세스, 컴포넌트 및 특징을 구현할 수 있는환경, 아키텍쳐 및 프레임워크의 기능 또는 사용 범위에 관한 임의의 제한을 제안하기 위한 것이 아니다. 따라서, 본원의 구현예는 다수의 환경 또는 아키텍쳐와 함께 동작하는 것이고, 범용 및 특수 목적용 컴퓨팅 시스템, 또는 프로세싱 기능을 갖는 다른 디바이스로 구현될 수 있다. 일반적으로, 도면과 관련하여 설명된 임의의 기능은 소프트웨어, 하드웨어(예를 들어, 고정 로직 회로) 또는 이들 구현예의 조합을 사용하여 구현될 수 있다. 본원에서 사용되는 용어 "모듈", "매커니즘" 또는 "컴포넌트" 일반적으로 사전설명된 기능을 구현하도록 구성될 수 있는 소프트웨어, 하드웨어, 또는 소프트웨어 및 하드웨어의 조합을 나타낸다. 예를 들어, 소프트웨어 구현의 경우에, 용어 "모듈", "매커니즘" 또는 "컴포넌트"는 프로세싱 디바이스 또는 디바이스(예를 들어, CPU 또는 프로세서) 상에서 실행될 때 특정 태스크 또는 동작을 수행하는 프로그램 코드(및/또는 서술문 타입 명령어)를 나타낼 수 있다. 프로그램 코드는 하나 이상의 컴퓨터 판독가능 메모리 디바이스 또는 다른 컴퓨터 저장 디바이스에 저장될 수 있다. 따라서, 본원에서 설명된 프로세스, 컴포넌트 및 모듈은 컴퓨터 프로그램 제품에 의해 구현될 수 있다.
본원에서 사용된 바와 같이, "컴퓨터 판독가능 매체"는 컴퓨터 저장 매체 및 통신 매체를 포함한다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 다른 데이터와 같은, 정보의 저장을 위한 임의의 방법 또는 기술에서 구현된 휘발성 및 비휘발성 매체, 제거가능 및 제거불가능 매체를 포함한다. 컴퓨터 저장 매체는, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 전기적으로 제거가능한 프로그래밍가능한 ROM(EEPROM), 플래쉬 메모리 또는 다른 메모리 기술, 컴팩트 디스크 ROM(CD-ROM), 디지털 범용 디스크(DVD) 또는 다른 광학 저장부, 자기 카세트, 자기 테이프, 자기 디스크 저장부 또는 다른 자기 저장 디바이스, 또는 컴퓨팅 디바이스에 의한 액세스를 위해 정보를 저장하는데 사용될 수 있는 임의의 다른 비통신 매체를 포함할 수 있지만, 이에 제한되지 않는다.
반대로, 통신 매체는 캐리어 파와 같은, 변조된 데이터 신호에서의 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 구현할 수 있다. 본원에서 정의된 바와 같이, 컴퓨터 저장 매체는 통신 매체를 포함하지 않는다.
또한, 이 개시는 도면에서 설명되고 도시된 바와 같은, 다양한 예시의 구현예를 제공한다. 그러나, 이 개시는 본원에서 설명되고 도시된 구현예에 제한되지 않지만, 당업자에게 알려져 있거나 알려질 수 있는 다른 구현예로 확장할 수 있다. 명세서에서 "일 구현예", "이 구현예", "이들 구현예", "일례", "일부 예시", "일부 구현예" 등에 대한 참조는 설명된 특정 특징, 구조, 또는 특성이 적어도 하나의 구현예 또는 예시에 포함되고, 명세서의 다양한 위치에서 이들 문구의 등장은 반드시 모두 동일한 구현예를 지칭하는 것이 아니다. 달리 언급되지 않으면, 제공되는 다양한 구현예 및 예시는 상호 배타적인 것이 아니고 개별적으로 또는 서로 조합하여 사용될 수 있다.
예시
하나 이상의 애플리케이션, 하나 이상의 디바이스 드라이버, 및 운영 체제를 포함하는 소프트웨어 스택의 속성을 포함하는 사양이 생성될 수 있다. 소프트웨어 스택의 속성은 명세서를 준수하는 것으로서 검증될 수 있다. 소프트웨어 스택이 사양을 준수하는 것으로서 검증되었다는 표시가 제공될 수 있다. 소프트웨어 스택의 속성이 사양을 준수한다는 증거가 제공될 수 있다. 예를 들어, 증거는 소프트웨어 스택의 기능적인 정확성을 증명할 수 있다. 다른 예시로서, 증거는 소프트웨어 스택의 관계 속성을 증명할 수 있다. 사양은 유한 상태 머신으로서 표현되는 하이 레벨 사양을 포함할 수 있다. 하이 레벨 언어 코드는 어셈블리 언어 코드로 컴파일링될 수 있다. 어셈블리 언어 코드의 속성은 사양을 준수하도록 검증될 수 있다. 소프트웨어 코드의 속성이 사양을 준수한다고 검증하기 이전에 사양이 로우 레벨 사양으로 변환될 수 있다.
소프트웨어 시스템의 하이 레벨 언어 구현은 어셈블리 언어 구현을 생성하도록 컴파일링될 수 있다. 소프트웨어 시스템에 대응하는 하이 레벨 사양은 로우 레벨 사양으로 변환될 수 있다. 어셈블리 언어 구현의 속성은 로우 레벨 사양을 준수하는 것으로서 검증될 수 있다. 머신 코드 구현은 어셈블리 언어 구현에 기초하여 생성될 수 있다. 머신 코드 구현은 신뢰할 수 있는 하드웨어 플랫폼과 같은, 신뢰할 수 있거나 안전한 하드웨어 상에서 실행될 수 있다. 예비 검증은 하이 레벨 언어 구현이 하이 레벨 사양을 준수한다는 것을 검증하도록 수행될 수 있다. 하이 레벨 사양은 적어도 하나의 유한 상태 머신으로서 표현될 수 있다. 어셈블리 언어 구현의 속성이 로우 레벨 사양을 준수한다고 검증하는 것은 어셈블리 언어 구현이 기능적으로 정확한 버전의 로우 레벨 사양을 구현하는지를 판정하는 것을 포함할 수 있다. 소프트웨어 시스템의 컴포넌트는 소프트웨어 시스템의 다른 컴포넌트를 손상시키는 것이 불가능한 것으로서 검증될 수 있다.
소프트웨어 시스템의 하이 레벨 언어 구현은 어셈블리 언어 구현을 생성하도록 컴파일링될 수 있다. 소프트웨어 시스템은 운영 체제, 하나 이상의 드라이버, 및 하나 이상의 애플리케이션을 포함할 수 있다. 소프트웨어 시스템의 기능적인 정확성이 검증될 수 있다. 어셈블리 언어 구현의 관계 속성이 검증될 수 있다. 소프트웨어 시스템의 기능적인 정확성을 검증하는 것은 소프트웨어 시스템의 정보 흐름 속성을 검증하는 것을 포함할 수 있다. 인증서는, (1) 공개 키가 개인 키에 대응하고, (2) 개인 키가 검증된 소프트웨어 시스템에만 알려져 있다는 것을 인증할 수 있다. 소프트웨어 시스템의 정확성은 소프트웨어 시스템의 각 컴포넌트를 검증함으로써 검증될 수 있다. 소프트웨어 시스템의 어셈블리 언어 구현은 전체로서 검증되는 단일 소프트웨어 프로그램을 포함할 수 있다. 소프트웨어 시스템의 제 1 컴포넌트는 소프트웨어 시스템의 제 2 컴포넌트의 제 2 사양과 간섭하는 것을 불가능하게 하는 것으로서 검증될 수 있다. 소프트웨어 시스템의 원격 동등성이 실증될 수 있다.
결론
청구 대상은 구조적 특징 및/또는 방법론적 동작에 특정한 언어로 설명되었지만, 첨부된 청구항에서 정의된 청구 대상은 위에서 설명된 특정 특징 또는 동작로 제한되지 않는다. 오히려, 위에서 설명된 특정 특징 및 동작은 청구항을 구현하는 예시의 형태로서 개시된다. 이 개시는 개시된 구현예의 임의의 그리고 모든 적응 또는 변형을 커버하기 위한 것이고, 다음의 청구항은 명세서에서 개시된 특정 구현예로 제한되는 것으로서 해석되어서는 안된다.

Claims (20)

  1. 컴퓨터로 구현되는, 소프트웨어를 자동으로 검증하는 방법으로서,
    하이 레벨(high-level) 언어로 작성된 소프트웨어 코드를 수신하는 단계 - 상기 소프트웨어 코드는 운영 체제 및 적어도 하나의 애플리케이션을 포함하는 복수의 컴포넌트를 포함함 - 와,
    상기 소프트웨어 코드를 상기 소프트웨어 코드에 대응하는 어셈블리 언어 코드를 생성하도록 컴파일링하는 단계와,
    상기 소프트웨어 코드에 의해 수행된 하나 이상의 기능을 특정하는 하이 레벨 사양(high-level specification)을 수신하는 단계와,
    상기 하이 레벨 사양에 적어도 부분적으로 기초하여 로우 레벨 사양(low-level specification)을 생성하는 단계와,
    상기 어셈블리 언어 코드의 출력이 비밀 데이터를 결정되게 할 수 없다는 것을 검증하는 단계 - 상기 비밀 데이터는 하나 이상의 개인 키를 포함함 - 와,
    상기 어셈블리 언어 코드가 상기 로우 레벨 사양에 따라 동작하여 상기 하이 레벨 사양에 의해 특정된 상기 하나 이상의 기능을 수행하는 것을 검증하는 단계와,
    상기 어셈블리 언어 코드가 상기 하나 이상의 기능을 수행하는 것으로 검증되었는다는 표시를 제공하는 단계를 포함하는
    소프트웨어 자동 검증 방법.
  2. 제 1 항에 있어서,
    상기 복수의 컴포넌트 중 제 1 컴포넌트가 상기 복수의 컴포넌트 중 제 2 컴포넌트를 손상(subverting)시키지 못한다는 것을 검증하는 단계를 더 포함하는
    소프트웨어 자동 검증 방법.
  3. 제 1 항에 있어서,
    상기 복수의 컴포넌트의 개별 컴포넌트와 상기 로우 레벨 사양의 대응 상태 머신 사이의 동등성(equivalence)을 검증하는 단계를 더 포함하는
    소프트웨어 자동 검증 방법.
  4. 제 1 항에 있어서,
    상기 하이 레벨 사양은,
    사전 조건, 사후 조건, 및 종료 메트릭 중 적어도 하나와,
    상기 소프트웨어 코드와 연관된 상태를 식별하는 하나 이상의 어써션(assertions)을 포함하고,
    상기 컴퓨터로 구현되는 방법은,
    상기 하나 이상의 어써션의 유효성(validity)을 검증하는 단계를 더 포함하는
    소프트웨어 자동 검증 방법.
  5. 제 1 항에 있어서,
    상기 소프트웨어 코드는 상기 소프트웨어 코드에 의해 입력된 복수의 상태에 관한 어써션을 포함하는
    소프트웨어 자동 검증 방법.
  6. 제 5 항에 있어서,
    상기 어셈블리 언어 코드가 상기 하나 이상의 기능을 수행하는 것을 검증하는 단계는,
    상기 소프트웨어 코드에 의해 입력된 상기 복수의 상태에 관한 상기 어써션이 모든 가능한 입력에 대해 유효하다는 것을 증명하는 단계를 포함하는
    소프트웨어 자동 검증 방법.
  7. 제 1 항에 있어서,
    상기 하이 레벨 사양은 상기 소프트웨어 코드에 의해 사용되는 특징 - 상기 특징은 상기 소프트웨어 코드가 사용하는 기능을 포함함 - 서브세트를 특정하는 관용적 사양(idiomatic specification)을 포함하는
    소프트웨어 자동 검증 방법.
  8. 제 1 항에 있어서,
    상기 어셈블리 언어 코드를 최적화하는 단계 - 상기 어셈블리 언어 코드는 중간 검증 언어를 사용하여 증거 의무(proof obligation)를 기술함 - 와,
    검증 엔진에 의해, 상기 어셈블리 언어 코드에 적어도 부분적으로 기초하여 상기 증거 의무에 대응하는 하나 이상의 검증 조건을 생성하는 단계와,
    추론 엔진에 의해, 상기 증거 의무를 검증하는 단계를 더 포함하는
    소프트웨어 자동 검증 방법.
  9. 소프트웨어를 자동으로 검증하는 컴퓨팅 장치로서,
    하나 이상의 프로세서와,
    상기 하나 이상의 프로세서에 의해 실행가능한 명령어를 저장한 하나 이상의 메모리 저장 장치를 포함하되, 상기 명령어는,
    하이 레벨 언어로 작성된 소프트웨어 코드를 수신하는 것 - 상기 소프트웨어 코드는 복수의 컴포넌트를 포함함 - 과,
    상기 소프트웨어 코드를 상기 소프트웨어 코드에 대응하는 어셈블리 언어 코드를 생성하도록 컴파일링하는 것과,
    상기 소프트웨어 코드에 의해 수행된 하나 이상의 기능을 특정하는 하이 레벨 사양(high-level specification)을 수신하는 것과,
    상기 하이 레벨 사양에 적어도 부분적으로 기초하여 로우 레벨 사양을 생성하는 것과,
    상기 어셈블리 언어 코드의 출력이 비밀 데이터가 결정되지 못하게 하는 것을 검증하는 것 - 상기 비밀 데이터는 하나 이상의 개인 키를 포함함 - 과,
    상기 어셈블리 언어 코드가 상기 로우 레벨 사양에 따라 동작하여 상기 하이 레벨 사양에 의해 특정된 상기 하나 이상의 기능을 수행하는 것을 검증하는 것과,
    상기 어셈블리 언어 코드가 상기 하나 이상의 기능을 수행하는 것으로 검증되었는다는 표시를 제공하는 것 포함하는 동작을 수행하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  10. 제 9 항에 있어서,
    상기 동작은,
    상기 소프트웨어 코드의 라인을 수신하는 것과,
    상기 하이 레벨 사양에 대해 상기 소프트웨어 코드의 라인을 검증하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  11. 제 9 항에 있어서,
    상기 동작은,
    상기 하나 이상의 기능 중 적어도 하나의 기능을 수행하는 상기 소프트웨어 코드의 라인을 수신하는 것과,
    상기 소프트웨어 코드의 라인이 상기 적어도 하나의 기능을 수행하는 것에 실패한 것을 결정하는 것과,
    상기 하이 레벨 사양의 실패한 사전조건이 강조된 에러 메시지를 디스플레이하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  12. 제 9 항에 있어서,
    상기 동작은,
    상기 하나 이상의 기능 중 적어도 하나의 기능을 수행하는 상기 소프트웨어 코드의 편집된 부분을 수신하는 것과,
    상기 소프트웨어 코드의 상기 편집된 부분이 상기 하나 이상의 기능 중 적어도 하나의 기능을 수행하는 것을 재검증하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  13. 제 9 항에 있어서,
    상기 동작은,
    상기 소프트웨어 코드의 제 1 파일을 수신하는 것 - 상기 제 1 파일은 이전에 검증되지 않은 상기 소프트웨어 코드의 제 2 파일의 인터페이스를 참조함 - 과,
    상기 제 2 파일을 재검증하지 않고, 상기 소프트웨어 코드의 상기 제 2 파일의 인터페이스를 가져오기(importing)하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  14. 제 9 항에 있어서,
    상기 동작은,
    상기 복수의 컴포넌트 중 제 1 컴포넌트가 상기 복수의 컴포넌트 중 제 2 컴포넌트를 손상(subverting)시킬 수 없다는 것을 검증하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  15. 제 9 항에 있어서,
    상기 동작은
    상기 소프트웨어 코드에 포함된 소프트웨어 애플리케이션의 다중 실행을 분석하는 것과,
    상기 다중 실행에 대응하는 다중 출력을 비교하는 것과,
    모든 가능한 실행 쌍에 대한 종속성을 결정하는 것을 더 포함하는
    소프트웨어 자동 검증용 컴퓨팅 장치.
  16. 하나 이상의 프로세서에 의해 실행가능한 명령어를 저장한 하나 이상의 메모리 저장 장치로서,
    상기 명령어는,
    하이 레벨 언어로 작성된 소프트웨어 코드를 수신하는 것 - 상기 소프트웨어 코드는 복수의 컴포넌트를 포함함 - 과,
    상기 소프트웨어 코드를 상기 소프트웨어 코드에 대응하는 어셈블리 언어 코드를 생성하도록 컴파일링하는 것과,
    상기 소프트웨어 코드에 의해 수행된 하나 이상의 기능을 특정하는 하이 레벨 사양을 수신하는 것과,
    상기 하이 레벨 사양에 적어도 부분적으로 기초하여 로우 레벨 사양을 생성하는 것과,
    상기 어셈블리 언어 코드의 출력이 비밀 데이터를 결정되게 할 수 없다는 것을 검증하는 것 - 상기 비밀 데이터는 하나 이상의 개인 키를 포함함 - 과,
    상기 어셈블리 언어 코드가 상기 로우 레벨 사양에 따라 동작하여 상기 하이 레벨 사양에 의해 특정된 상기 하나 이상의 기능을 수행하는 것을 검증하는 것과,
    상기 어셈블리 언어 코드가 상기 하나 이상의 기능을 수행하는 것으로 검증되었는다는 표시를 제공하는 것을 포함하는
    하나 이상의 메모리 저장 장치.
  17. 제 16 항에 있어서,
    상기 동작은
    상기 소프트웨어 코드의 기능적 정확성(functional correctness)을 증명하는 것과,
    상기 소프트웨어 코드의 관계 속성을 증명하는 것을 더 포함하는
    하나 이상의 메모리 저장 장치.
  18. 제 16 항에 있어서,
    상기 하이 레벨 사양이 적어도 하나의 유한 상태 머신으로서 표현되는
    하나 이상의 메모리 저장 장치.
  19. 제 16 항에 있어서,
    상기 동작은
    상기 어셈블리 언어 코드가 상기 로우 레벨 사양의 기능적으로 정확한 버전(functionally correct version)을 구현하는 것을 결정하는 것을 더 포함하는
    하나 이상의 메모리 저장 장치.
  20. 제 16 항에 있어서,
    상기 동작은
    상기 복수의 컴포넌트 중 제 1 컴포넌트가 상기 복수의 컴포넌트 중 다른 컴포넌트를 손상시키지 않는다는 것을 검증하는 것을 포함하여, 상기 복수의 컴포넌트의 각 컴포넌트를 검증함으로써 상기 소프트웨어 코드의 정확성을 검증하는 것을 더 포함하는
    하나 이상의 메모리 저장 장치.
KR1020177008884A 2014-10-02 2015-10-01 소프트웨어 시스템의 자동화된 검증 기법 KR102396071B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/505,204 US9536093B2 (en) 2014-10-02 2014-10-02 Automated verification of a software system
US14/505,204 2014-10-02
PCT/US2015/053408 WO2016054321A1 (en) 2014-10-02 2015-10-01 Automated verification of a software system

Publications (2)

Publication Number Publication Date
KR20170063662A KR20170063662A (ko) 2017-06-08
KR102396071B1 true KR102396071B1 (ko) 2022-05-09

Family

ID=54293400

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177008884A KR102396071B1 (ko) 2014-10-02 2015-10-01 소프트웨어 시스템의 자동화된 검증 기법

Country Status (7)

Country Link
US (1) US9536093B2 (ko)
EP (1) EP3201819B1 (ko)
KR (1) KR102396071B1 (ko)
CN (1) CN107111713B (ko)
BR (1) BR112017005605A2 (ko)
RU (1) RU2017110787A (ko)
WO (1) WO2016054321A1 (ko)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US10539609B2 (en) * 2014-12-08 2020-01-21 Nxp Usa, Inc. Method of converting high-level test specification language to low-level test implementation language
US9823904B2 (en) * 2014-12-18 2017-11-21 International Business Machines Corporation Managed assertions in an integrated development environment
US9747082B2 (en) 2014-12-18 2017-08-29 International Business Machines Corporation Optimizing program performance with assertion management
US9703552B2 (en) 2014-12-18 2017-07-11 International Business Machines Corporation Assertions based on recently changed code
US9678855B2 (en) 2014-12-30 2017-06-13 International Business Machines Corporation Managing assertions while compiling and debugging source code
US10176094B2 (en) 2015-06-30 2019-01-08 Renesas Electronics America Inc. Common MCU self-identification information
US10032031B1 (en) 2015-08-27 2018-07-24 Amazon Technologies, Inc. Detecting unknown software vulnerabilities and system compromises
US10019572B1 (en) * 2015-08-27 2018-07-10 Amazon Technologies, Inc. Detecting malicious activities by imported software packages
US10402584B1 (en) * 2015-10-01 2019-09-03 Hrl Laboratories, Llc System and method for translating security objectives of computer software to properties of software code
US10466977B2 (en) * 2015-10-11 2019-11-05 Renesas Electronics America Inc. Data driven embedded application building and configuration
TWI590095B (zh) * 2016-05-19 2017-07-01 緯創資通股份有限公司 軟體功能驗證系統及其驗證方法
US9977725B2 (en) * 2016-08-26 2018-05-22 Cisco Technology, Inc. Automatic classification and parallel processing of untested code in a protected runtime environment
US10452459B2 (en) 2016-12-09 2019-10-22 Microsoft Technology Licensing, Llc Device driver telemetry
US10467082B2 (en) * 2016-12-09 2019-11-05 Microsoft Technology Licensing, Llc Device driver verification
US10977384B2 (en) 2017-11-16 2021-04-13 Microsoft Technoogy Licensing, LLC Hardware protection for differential privacy
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11487520B2 (en) * 2017-12-01 2022-11-01 Cotiviti, Inc. Automatically generating reasoning graphs
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US10902149B2 (en) 2018-02-01 2021-01-26 Microsoft Technology Licensing, Llc Remote testing analysis for software optimization based on client-side local differential privacy-based data
CN109240907B (zh) * 2018-07-26 2021-07-27 华东师范大学 基于霍尔逻辑的嵌入式实时操作系统的自动化验证方法
US10977375B2 (en) * 2018-08-10 2021-04-13 International Business Machines Corporation Risk assessment of asset leaks in a blockchain
CN109446056B (zh) * 2018-09-11 2023-03-21 平安科技（深圳）有限公司 代码验证方法、装置、电子设备及介质
CN112468473B (zh) * 2018-11-16 2023-10-24 创新先进技术有限公司 可信应用程序的远程证明方法及装置、电子设备
US20200280550A1 (en) * 2019-02-28 2020-09-03 Nok Nok Labs, Inc. System and method for endorsing a new authenticator
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110347588B (zh) * 2019-06-04 2024-03-15 宁波谦川科技有限公司 软件验证方法、装置、计算机设备和存储介质
WO2020035089A2 (en) 2019-11-08 2020-02-20 Alipay (Hangzhou) Information Technology Co., Ltd. System and method for blockchain-based decentralized application development
CN111373402B (zh) 2019-11-08 2022-03-25 支付宝(杭州)信息技术有限公司 轻量去中心化应用平台
CN112464174B (zh) * 2020-10-27 2023-09-29 华控清交信息科技(北京)有限公司 验证多方安全计算软件的方法、装置和用于验证的装置
US20230084495A1 (en) * 2021-09-14 2023-03-16 Apple Inc. Verifiable machine code
CN116820419A (zh) * 2022-03-22 2023-09-29 瑞昱半导体股份有限公司 源代码校验方法及非暂态计算机可读存储介质装置
US11921616B1 (en) * 2022-03-29 2024-03-05 Amazon Technologies, Inc. Retaining Dafny specifications
CN114995799B (zh) * 2022-07-18 2022-10-25 新华三半导体技术有限公司 一种汇编代码生成方法、装置及电子设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060143689A1 (en) 2004-12-21 2006-06-29 Docomo Communications Laboratories Usa, Inc. Information flow enforcement for RISC-style assembly code
WO2010041258A1 (en) 2008-10-10 2010-04-15 Safend Ltd. System and method for validating and controlling applications

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0410047D0 (en) * 2004-05-05 2004-06-09 Silverdata Ltd An analytical software design system
US20060041873A1 (en) * 2004-08-19 2006-02-23 Cisco Technology, Inc. Computer system and method for verifying functional equivalence
JP2008511934A (ja) * 2004-08-31 2008-04-17 インターナショナル・ビジネス・マシーンズ・コーポレーション エンタープライズ・データ統合システムのためのアーキテクチャ
US8104021B2 (en) 2006-06-09 2012-01-24 Microsoft Corporation Verifiable integrity guarantees for machine code programs
US20080271001A1 (en) * 2006-09-11 2008-10-30 Yo Nonomura Method of generating program, information processing device and microcomputer
US8326592B2 (en) * 2007-12-21 2012-12-04 Cadence Design Systems, Inc. Method and system for verifying electronic designs having software components
CN101251823B (zh) * 2008-03-17 2010-08-25 北京天碁科技有限公司 Dsp汇编语言程序验证方法及其装置
CN101446905B (zh) * 2008-12-29 2012-06-27 飞天诚信科技股份有限公司 编译方法
US8201119B2 (en) * 2010-05-06 2012-06-12 Synopsys, Inc. Formal equivalence checking between two models of a circuit design using checkpoints
US8839363B2 (en) 2011-04-18 2014-09-16 Bank Of America Corporation Trusted hardware for attesting to authenticity in a cloud environment
US9075996B2 (en) 2012-07-30 2015-07-07 Microsoft Technology Licensing, Llc Evaluating a security stack in response to a request to access a service
US9317682B1 (en) * 2012-12-07 2016-04-19 Hrl Laboratories, Llc Library-based method for information flow integrity enforcement and robust information flow policy development

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060143689A1 (en) 2004-12-21 2006-06-29 Docomo Communications Laboratories Usa, Inc. Information flow enforcement for RISC-style assembly code
WO2010041258A1 (en) 2008-10-10 2010-04-15 Safend Ltd. System and method for validating and controlling applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Xinyu Feng 외 4인, 'Modular Verification of Assembly Code with Stack-Based Control Abstractions', ACM SIGPLAN Notices Volume 41 Issue, 2006.06.11, pp.401-414

Also Published As

Publication number Publication date
EP3201819B1 (en) 2021-12-01
RU2017110787A (ru) 2018-10-01
WO2016054321A1 (en) 2016-04-07
EP3201819A1 (en) 2017-08-09
US9536093B2 (en) 2017-01-03
US20160098562A1 (en) 2016-04-07
CN107111713B (zh) 2020-02-07
BR112017005605A2 (pt) 2017-12-12
KR20170063662A (ko) 2017-06-08
CN107111713A (zh) 2017-08-29

Similar Documents

Publication Publication Date Title
KR102396071B1 (ko) 소프트웨어 시스템의 자동화된 검증 기법
US10148442B2 (en) End-to-end security for hardware running verified software
Sinha et al. Moat: Verifying confidentiality of enclave programs
Hawblitzel et al. Ironclad apps:{End-to-End} security via automated {Full-System} verification
Delaune et al. Formal analysis of protocols based on TPM state registers
Pappas et al. CloudFence: Data flow tracking as a cloud service
Corin et al. Taint analysis of security code in the KLEE symbolic execution engine
Bai et al. Trustfound: Towards a formal foundation for model checking trusted computing platforms
Wang et al. On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL
Lal et al. Blockchain testing: Challenges, techniques, and research directions
Beekman Improving cloud security using secure enclaves
Wichelmann et al. Microwalk-ci: practical side-channel analysis for javascript applications
Fröschle et al. Analysing PKCS# 11 key management APIs with unbounded fresh data
Cuéllar et al. Cheesecloth:{Zero-Knowledge} Proofs of Real World Vulnerabilities
Vella et al. RV-TEE: secure cryptographic protocol execution based on runtime verification
Barbon et al. Privacy analysis of android apps: implicit flows and quantitative analysis
CS Machado et al. Software control and intellectual property protection in cyber-physical systems
Zhang et al. Formal analysis of TPM2. 0 key management APIs
Xu et al. A symbolic model for systematically analyzing TEE-based protocols
Song et al. A collective attestation scheme towards cloud system
Wang et al. Practical verifiable computation–A MapReduce case study
Ali et al. SRP: An Efficient Runtime Protection Framework for Blockchain-based Smart Contracts
Tan et al. Formal modeling and verification of cloudproxy
Sinha et al. Verification of Confidentiality Properties of Enclave Programs
Debes Convincing Without Revealing: Strategies for Facilitating Remote Attestation under Weakened Trust Assumptions using Privacy-Enhancing Technologies

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant