20160708

1. [SP’15] VC3: Trustworthy Data Analytics in the Cloud Using SGX (paper)


클라우드 컴퓨팅이 보안 문제를 일으키고 있다. 사용자는 데이터를 클라우드에서 처리하는데, 이 과정에서 데이터가 유출될 수 있다. 디스크의 데이터를 암호화할 수 있지만, 연산 과정에서는 복호화되어야 하므로 불충분하다. Fully homomorphic 암호화를 사용할 수 있지만, 비효율적이다. 지금까지 많은 제안이 있었지만 제약이 있다. 이 연구에서 제안하는 VC3는 신뢰할 수 없는 컴퓨터에서 MapReduce 연산해도 안전하게 데이터를 보호한다.

1) Background: MapReduce & Intel SGX
MapReduce는 데이터 분석에서 흔히 쓰이는 프레임워크이다. 많은 양의 데이터를 분산해서 처리한 다음에, 키로 그룹지어 그 결과를 취합한다. 아주 단순한 프레임워크이고, 데이터 분석에 큰 도움이 된다. Software Guard Extensions(SGX)는 Intel에서 제공하는 보안 기술이다. 메모리의 특정 영역을 다른 메모리로부터 격리해주고, 임의의 접근을 막아준다. SGX의 메모리 영역이 캐시 라인에서 쫓겨날 때에는 암호화되며, TPM-like feature: sealing keys, local/remote attestation를 제공하며, 빠른 메모리 입출력을 제공한다.

2) Design Overview
데이터가 SGX 밖에 있을 때에는 암호화한 상태로 이동하도록 하고, SGX에서는 SGX의 기능을 사용해 연산하는 것이 목적이다. 이를 달성하기 위해서 해야 하는 여러 가지가 있다. 1) TCB를 최소화해야 한다. 2) 모든 연산 과정에서의 무결성을 보장해야 한다. 3) 현재 존재하는 클라우드 소프트웨어와 통합되어야 한다. 4) 악의적인 메모리 접근으로부터 보호되어야 한다.

먼저 어떻게 TCB를 최소화할 수 있는가?: 간단히 MapReduce 프레임워크를 따라 C++로 사용자가 사용하고자 하는 코드를 짠다. 그리고 이를 enclave 라이브러리와 통합해 enclave에 올린다(mapred.dll). TCB는 mapred.dll + SGX processor가 되는 것. 5500 LOC 정도만 신뢰하면 된다.

3) Lightweight Protocols
그 다음으로 어떻게 경량, 신뢰할 수 있는 프로토콜을 만들 것인가?: 키 교환과 인증 프로토콜이 필요함. 그리고 작업 실행은 일반적인 MapReduce 방식을 따른다. 다만 다른 것이 있는데, 각 노드는 작업 이후에 secure summary를 연산하고, 이를 이용해 연산 과정이 공격당한 것이 아닌지 확인할 수 있다.

4) Compiler-enforced Invariants
저수준의 코드가 enclave를 공격할 수 있으며, 이를 방어하기 위해 region self-integrity를 확인한다. Enclave 코드가 신뢰되지 않은 가상 주소 공간을 참조할 수 있다는 것이 문제이다. 초기화되지 않은 포인터에 쓰기 또는 읽기 연산을 수행할 수 있다는 것이 근본적인 문제이다. 이를 막기 위해 두 개의 컴파일러가 강제하는 region write-integrity, region read-write-integrity를 제안한다. Region write-integrity는 포인터 쓰기를 enclave 내로 제약하며, heap 할당을 enclave 내로 제약한다. Region read-write-integrity는 region write-integrity에 추가로 읽기 연산이 enclave 밖으로 나가지 못하도록 제약하는 것. Bitmap을 설정하여, 특정 메모리 영역을 쓸 수 있는지 아닌지를 결정한다.

5) Evaluation
Window Server 2012를 VC3에 구현해서 실험함. 컴파일러는 Microsoft C++ compiler 18에 구현함. 7개의 어플리케이션을 대상으로 실험함. Hadoop의 성능 오버헤드는 1%를 넘지 않음. Standalone에서의 성능 오버헤드는 4.3%~24.5%에 달함.


2. [SP’15] CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization (paper)


5년짜리 프로젝트. Software compartmentalization은 소프트웨어를 분리하고 격리해서, 각 소프트웨어에게 최소한의 권한를 주는 것. 각 컴포넌트에 최소한의 권한을 줌으로써 보안 수준을 높일 수 있다. Compartmentalization 기법은 다양하게 구현될 수 있다. Compartmentalization 방식에 따라 보안성, 복잡성, 성능이 달라지게 됨. 주로 프로세스 모델에서 오버헤드가 발생한다. 첫째로 Page table, translation look-aside buffer(TLB)가 문제가 됨. 프로세스를 생성할 때마다 페이지 테이블이 메모리 공간을 차지하게 됨. 그리고 가상 메모리를 지원하기 위한 TLB가 프로세서의 한 부분을 차지하고 있어서 문제가 됨. 둘째로 여러 개의 주소 공간과 IPC가 프로그래밍을 어렵게 만든다. CHERI capability model에 대한 많은 논문을 발표함.
ISCA 2014에 capability model에 기반한 메모리 보호 기법에 대해 발표함. Capability는 권한에 대한 토큰이다. 객체를 포인터가 아닌 capability로 접근. 그리고 메모리에 태그를 추가해 capability를 따르도록 함. 이러한 모델이 현재의 MMU 구조와 잘 맞는다. ASPLOS 2015에서는 capability를 지원하기 위한 컴파일러 지원에 대해 발표함. C pointer를 capability로 변환함.

virtual memory vs capabilities.PNG

가상 메모리와 capability를 비교. CHERI에서는 가상 메모리와 capability 모두를 사용함(hybrid). 가상 메모리는 가상 주소와 페이지를 보호하기에 적합하다. 상대적으로 coarse grained 하다. Capability는 포인터, 자료구조 단위로 보호한다. 어플리케이션 자체를 보고자 하는 접근이며, 따라서 조금 더 프로그래머 친화적이다. 하드웨어 측면에서 가상 메모리는 페이지 테이블, MMU, TLB를 필요로 한다. Capability는 capability register, tagged memory를 필요로 한다. 256bits 메모리마다 1 bit의 capability tag가 필요하다. 가상 메모리는 TLB, page table, lookups, shootdown 오버헤드가 발생한다. Capability는 per-pointer overhead, context switching overhead가 발생한다. 가상 메모리 기법은 수십에서 수백개 정도의 compartment를 제공 가능. 하지만 그 이상으로 수가 늘어나게 되면 TLB가 감당하지 못한다. Capability는 수천개 정도의 compartment를 제공. 256-bit의 capability 레지스터가 필요하다. 가상화는 격리와 가상화를 목표로 하고, capability model은 메모리 공유를 목표로 한다.

CHERI capabilities.PNG

CHERI capability는 256-bit capability가 필요하다. Capability는 데이터에 대한 포인터이다. 메모리에 대한 특정 영역을 잡는다고 보면 된다. Capability는 monotonic하다. 축소는 가능하지만 확장은 가능하지 않다. Capability integrity가 보장되는지 확인하기 위해 1-bit tag를 추가한다. Sealed bit bit는 변경이 가능한 데이터인지 아닌지를 지정한다.

object capability call-return.PNG

application implications.PNG


3. [SP’15] Virtual Proofs of Reality and their Physical Implementation (paper)


1) Basic Idea and Basic Setting of Virtual Proofs
Virtual proofs란 무엇인가? 두 개의 다른 로컬 시스템 S1, S2가 있다고 하자. S1과 S2는 디지털 채널로 연결되어 있음. S1에 있는 prover가 물리적인 조건에 대해 증명하고, S2에 있는 verifier가 이를 검증하는 상황이다. 예를 들어, 온도 / 습도 / 압력, 또는 데이터가 올바른지, 물리적인 프로세서가 올바른지 등을 검증해야 하는 상황이 있을 수 있다. 그런데 문제는 통신에 일반적으로 사용되는 키를 사용하지 않는다면 어떻게 그 검증이 옳다는 것을 믿을 수 있는가? 그런데, 왜 이런 조건을 가정하는가? 두 가지 이유가 있다. 1) 전통적인 암호화 문제를 물리적인 것까지 확장할 수 있다. 2) 키는 공격 지점이 될 수 있다. 따라서 키를 제거함으로써 attack surface를 줄일 수 있다. 그런데 이렇게 제약된 상황에서도 안전한 통신이 가능한가?

2) Virtual Proofs of Distance
Prover가 주장하는 두 물체 사이의 거리가 정말 맞는지 verifier가 어떻게 확인할 수 있는가? Opticla PUFs를 사용한다. 두 개의 빛을 산란하는 물체를 겹치고, 레이저를 쏘면 간섭 패턴이 보일 것. 이러한 간섭 패턴은 두 개의 빛 산란 물체, 물체 사이의 거리, 그리고 레이저의 특성(P, alpha)에 따라 결정된다. Verifier가 미리 정해진 거리와 (P, alpha)에 대한 간섭 패턴을 기록해둔다면, prover가 올바른 거리에 있는지 알 수 있다.

3) Virtual Proofs of Temperature
Prover가 주장하는 특정 시스템의 온도가 정말 맞는지 verifier가 어떻게 확인할 수 있는가? Temperature-sensitive electrical strong PUF를 사용하면 된다. 특정 온도에서 특정 값을 반환하는 PUF 함수를 만들어 전달하면 된다. 같은 방식으로 fingerprint를 검증하면 온도가 정말 맞는지 확인할 수 있다. 이를 사용하면 키 없이 온도 센서를 만들 수 있다.

4) Virtual Proofs of Destruction
Prover가 특정 시스템에서 특정 물체를 완벽히 파괴했다고 주장하는 것이 정말 맞는지 verifier가 어떻게 확인할 수 있는가? 현재까지는 이러한 문제를 해결하기 위한 기법은 없었다. 여기에서는 두 가지 기법을 제안한다. 1) PUF 안에 PUF를 집어넣는 구조가 있을 수 있다. 밖에 있는 PUF를 파괴해야만 안에 있는 PUF를 사용할 수 있도록 만들면 된다. 2) Quantum protocol.


4. Using Hardware Features for Increased Debugging Transparency (paper)


1) Motivation
악성 코드의 공격은 계속해서 늘어나고 있음. Symantec에서는 하루 247,000건의 공격이 발생한다고 함. 컴퓨터 시스템에서 실행 중인 어플리케이션은 취약점을 갖고 있다. 악성 코드를 정확히 분석하고 대응하는 것이 중요하다. 현재까지는 가상화된 시스템에서 악성 코드 분석을 진행했다. 가상 머신 안에서 악성 코드를 실행하고, 그 밖에서 분석 도구를 사용했다. 이러한 접근에 제약이 있다. TCB가 너무 크다는 것이다. Xen은 500K LOC의 코드 길이를 갖는다. 그리고 하이퍼바이저 자체의 취약점이 있을 것으로 예상된다. 하이퍼바이저에 대한 루트킷은 분석하지 못한다는 단점이 있다. 그리고 안티디버깅 기법을 적용한 악성 코드는 분석하기 어렵다는 문제가 있다. 그리고 성능이 많이 떨어진다는 문제가 있다. 이 연구에서는 bare-metal 디버깅 시스템인 MalT를 제안한다. System Management Mode를 악성 코드 분석에 사용하는 것이다. 악성 코드 분석 도구를 하이퍼바이저 레벨에서 SMM 레벨로 내리는 것이다.

2) Background: System Management Mode(SMM)
System Management Mode(SMM)은 x86 아키텍쳐에만 있는 특별한 CPU 모드이다. 이는 하드웨어 기반 격리 환경을 제공하기 위해 사용할 수 있다. 원래는 전력 관리와 같은 기능을 지원하고자 만들어진 기능이다. System Management RAM(SMRAM)을 갖는데, 이는 운영체제에서 접근 불가능하다. SMM에 접근하는 방법은 System Management Interrupt(SMI)를 발생시키는 것이다. 다시 보호 모드로 들어가기 위해서는 RSM 명령어를 실행하면 된다. 일반적으로 SMI를 발생시키는 방법에는 두 가지가 있다. Software-based, hardware based 기법이 있다. Software based 방법에서는 Southbridge datasheet에 있는 I/O port에 쓰기를 수행하면 된다. Hardware based 방법에서는 네트워크 카드, 키보드, 하드웨어 타이머 등을 사용할 수 있다. SMM은 BIOS의 일부이며, Firmware에 속한다.

3) System Architecture

MalT system architecture.PNG

MalT의 시스템 아키텍쳐를 소개한다. 전통적으로 악성 코드 분석은 가상화된 환경 또는 에뮬레이션을 사용한다. MalT는 bare-metal 환경에서 악성 코드를 분석함으로써 안티디버깅, 안티 가상화, 안티 에뮬레이션 기법을 우회할 수 있다. Step-by-step 실행을 구현했다. 명령어 단위로 실행하도록 만들수 있음. Performance counter를 사용해 명령어 갯수를 셀 수 있는데, 이 때 오버플로우가 발생하도록 하여 명령어 단위로 분석할 수 있다.

4) Evaluation: Transparency and Performance
Transparency와 performance 측면에서 성능을 평가함. 투명성을 확인하기 위해 실행 환경과 디버거 자체를 검증해보았음. SMM을 사용함으로써 transparency를 더 높임. 디버거 자체로 인한 영향도 적어짐. 여전히 완벽한 transparency를 확보하지는 못함. Performance overhead를 측정하기 위해서 AMD LE-1250을 사용함. 성능 오버헤드가 크지 않은 편이었다.

5) Conclusions and Future Directions
SMM을 사용해 bare-metal 디버깅 시스템인 MalT를 개발함. IDA pro와 같은 것을 MalT와 인터페이스를 맞추어 사용할 수 있을 것이라고 생각함.


5. Neural network에 대한 영상


https://www.youtube.com/channel/UC9OeZkIwhzfv-_Cb7fCikLQ

Advertisements
Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

누적 방문자 수
  • 88,610 hits
%d bloggers like this: