SGX-enclave 활용
use case
related work
프로그램을 각각 component로 나눈다
필요한 이유
제한된 리소스 (mem)
enclave간의 semantic gap
coarsegrained
finegrained
drone case
remote server에서 multi user에게 제공하는 서비스/ web service?
구현 이슈
모든 프로세스가 share하는 부분
설명 : 기능별로 나눠지는 부분
libc-wrapper
third-party lib
여러 센서들
다른 프로세스에서 돌아야 함
다 다른 enclave로 이용
RPC로 (polling방식)
목적에 의해 enclave들이 나눠졌을 때, 각 enclave들이 서로에게 영향을 끼치지 말아야 함
SFI
dynamic permission
한 프로세스? 여러 프로세스?
src-dst가 보장 X
attestation을 해도 내 데이터의 flow를 보장 X
중간 component가 compromised되면 보장 X
Android lib에서는 어떻게 처리/
component들을 분리하는 방법
SFI
각각 enclave로 나누기
context switch overhead가 없는 대신에 추가적인 instruction overhead가 있다.
HFI ( armlock arm domain)
기존의 기작들은 커널이 볼 수 있었음
나누기 기준
한 프로세스 내
다른 프로세스 일 때
CPS
web에서 메모리 관리
3-party lib
SFI보다 나은 점
src가 다른 부분에 있을 때
click to edit
여러 디바이스들이 한꺼번에 사용될 때
src가 compromised될 때
dst가 compromised될 때
중간 component 들이 compromised될 떄
principled
기존 코드를 변경하지 않는다
데이터 제공자인 사용자는 데이터 흐름을 확인할 수 있다.
데이터 제공자가 자신의 데이터가 원하는 곳으로 가는지 보장할 수 있는가?
데이터는 지정된 flow로만 갈 수 있다
sgx는 sgx끼리 attestation이 되어 있으면 무조건 data를 보낸다. 하지만 어떻게 사용하는지는 중요하지 X
나누는 기준
한 디바이스 내에 있을 때
센서 데이터는 sgx IO 가 아직 서포트 안함
여러 디바이스를 복합적으로 사용할 때,
face verification
smart home
외부에서 보내온 sensitive한 데이터를 활용
web?
process separation
context switch overhead가 있음
역시 context switch overhead가 있음
한 프로세스 내에 있을 때
third party library?
여러 데이터들을 사용
ML training
여러 컴포넌트들을 거침
데몬들?
memchached
안드로이드 프레임워크/ 서비스 프로바이더 퍼미션 based
SFI가 나은지 enclave로 나누는 것이 나은지 고민
flowfence고민
SFI vs Enclave vs HFI
redis server, db server로 웹 구축
SFI를 복합적으로 사용?
여러 벤더들이 코드를 만듦
DFI 구현
opaque handle table
DFI