CPU-bound ME, Intel SGX, AMD SME/SEV

1. Мейнстрим технологии шифрованной
памяти
CPU-bound ME, Intel SGX, AMD SME/SEV
В. А. Сартаков
12 января 2018 г.
sartakov@ksyslabs.org

2. Intro

3. Intro
Оперативная память представляет собой массивы конденсаторов
Способность конденсатора удерживать заряд определяется его
линейными размерами и свойствами диэлектрика внутри
Уменьшение линейных размеров затрудняет удержание заряда
Даже при отсутствии внешнего питания массивы конденсаторов
способны сохранять значения
Это не делает оперативную память персистентной, но создает
угрозу безопасности
1

4. Intro
Рис. 1: Заморозка модулей памяти, Source: Halderman at. al.
2008(9) год: Атака «холодной перезагрузки» (cold-boot, CB) [21]
• Баллончик сжатого воздуха – 10 e
• Времени достаточно чтобы извлечь память из атакуемого
устройства и поместить в устройство атакующего
• Можно даже не извлекать память, а перегрузить устройство в
свою систему
2

5. Intro
Рис. 2: Обфускация данных в DDR3 и DDR4, Source: Yitbarek, at. al.
• Обфускация данных в DDR4 памяти и Skylake процессорах не
является преградой [13]
3

6. Intro
В настоящее время существует три направления борьбы с
подобными атаками:
• Trusted Platform Modules (TPM)
4

7. Intro
В настоящее время существует три направления борьбы с
подобными атаками:
• Trusted Platform Modules (TPM)
• Программное шифрование памяти
4

8. Intro
В настоящее время существует три направления борьбы с
подобными атаками:
• Trusted Platform Modules (TPM)
• Программное шифрование памяти
• Аппаратное шифрование памяти
4

9. Агенда
1. Intro
2. CPU-bound ME
3. Аппаратное шифрование
4. Intel Software Guard eXtensions (SGX)
5. Особенности Анклавов
6. Обзор SGX работ
7. AMD Secure Memory Encryption (SME)
8. AMD Secure Encrypted Virtualization (SEV)
5

10. CPU-bound ME

11. CPU-bound ME
CPU-bound memory encryption – Программное шифрование памяти
внутри процессора рассматривалось в научной среде в качестве
«бесплатной» альтернативы TPM.
Технический вопрос: как осуществлять шифрование эффективно и
не выгружать при этом ключи шифрования в память?
Проекты:
• Armored [16] – шифрование для ОС Android
6

12. CPU-bound ME
CPU-bound memory encryption – Программное шифрование памяти
внутри процессора рассматривалось в научной среде в качестве
«бесплатной» альтернативы TPM.
Технический вопрос: как осуществлять шифрование эффективно и
не выгружать при этом ключи шифрования в память?
Проекты:
• Armored [16] – шифрование для ОС Android
• PRIME [14] – RSA шифрование с использованием SSE и AVX
регистров процессора
6

13. CPU-bound ME
CPU-bound memory encryption – Программное шифрование памяти
внутри процессора рассматривалось в научной среде в качестве
«бесплатной» альтернативы TPM.
Технический вопрос: как осуществлять шифрование эффективно и
не выгружать при этом ключи шифрования в память?
Проекты:
• Armored [16] – шифрование для ОС Android
• PRIME [14] – RSA шифрование с использованием SSE и AVX
регистров процессора
• copker [19] – хранение ключа и компонентов в кэше
6

14. CPU-bound ME
CPU-bound memory encryption – Программное шифрование памяти
внутри процессора рассматривалось в научной среде в качестве
«бесплатной» альтернативы TPM.
Технический вопрос: как осуществлять шифрование эффективно и
не выгружать при этом ключи шифрования в память?
Проекты:
• Armored [16] – шифрование для ОС Android
• PRIME [14] – RSA шифрование с использованием SSE и AVX
регистров процессора
• copker [19] – хранение ключа и компонентов в кэше
• PixelVault [39] – Использует регистры GPU
6

15. CPU-bound ME
CPU-bound memory encryption – Программное шифрование памяти
внутри процессора рассматривалось в научной среде в качестве
«бесплатной» альтернативы TPM.
Технический вопрос: как осуществлять шифрование эффективно и
не выгружать при этом ключи шифрования в память?
Проекты:
• Armored [16] – шифрование для ОС Android
• PRIME [14] – RSA шифрование с использованием SSE и AVX
регистров процессора
• copker [19] – хранение ключа и компонентов в кэше
• PixelVault [39] – Использует регистры GPU
• Mimosa [20] – в дополнении к CPU-bound ME защищает
шифрование средствами транзакционной памяти (HTM)
6

16. CPU-bound ME
Интересные проекты:
• BitVisor [34]
7

17. CPU-bound ME
Интересные проекты:
• BitVisor [34]
• TreVisor [27] – шифрованый носитель поверх BitVisor
7

18. CPU-bound ME
Интересные проекты:
• BitVisor [34]
• TreVisor [27] – шифрованый носитель поверх BitVisor
• TRESOR [26] и Loop-Amnesia [36] – шифраторы блочных
устройств
7

19. CPU-bound ME
Интересные проекты:
• BitVisor [34]
• TreVisor [27] – шифрованый носитель поверх BitVisor
• TRESOR [26] и Loop-Amnesia [36] – шифраторы блочных
устройств
• Успешная атака на TRESOR [5]
7

20. CPU-bound ME
Шифрование затратно по ресурсам и существенно увеличивает
время доступа к памяти. Попытки повысить эффективность:
• Cryptkeeper [29] – избирательный подход, шифрует только редко
используемую память. По сути шифрованный swap внутри
памяти
8

21. CPU-bound ME
Шифрование затратно по ресурсам и существенно увеличивает
время доступа к памяти. Попытки повысить эффективность:
• Cryptkeeper [29] – избирательный подход, шифрует только редко
используемую память. По сути шифрованный swap внутри
памяти
• Ramcrypt [17] – «скользящее окно» внутри которого данные
хранятся в открытом виде, в то время как неиспользуемые в
данный момент страницы памяти хранятся в зашифрованном
8

22. CPU-bound ME
Несмотря на практическую ценность всех этих работ, они все
перестали иметь значение после появления аппаратного
шифрования памяти в массовых процессорах компаний Intel и
AMD.
9

23. Аппаратное шифрование

24. Аппаратное шифрование
Аппаратное шифрование памяти – логическое развитие прикладной
криптографии
Начало 90ых – Pretty Good Privacy (PGP) для шифрования файлов и
почты
Середина 90ых [22] – SSL протокол разработанный Netscape
Далее – шифрованные носители, удешевление и ускорение чипов
Появление шифрованной памяти было вопросом времени.
10

25. Аппаратное шифрование
В научной среде концепции реализации аппаратного шифрования
памяти были описаны в нескольких проектах:
2007 Aegis [37] – Концепция SoC с дополнительным ядром для
исполнения только зашифрованных операций извлеченных из
недоверенной памяти
2007 AISE [31] – шифрование страниц памяти в режиме счетчика, с
использованием Merkle Tree и своих Bonsai Merkle Trees
2006 CryptoPage [12] – Merkle Tree, integrity protection, memory
encryption
11

26. Аппаратное шифрование
Длительное время эти проекты оставались концепциями или имели
узкую специализацию
AES-NI расширение Intel в начале 2010х
2015 Анонс Intel Software Guard eXtensions (SGX) в процессорах
Skylake
2017 Выход AMD EPIC процессоров с поддержкой SME и SEV
12

27. Intel Software Guard
eXtensions (SGX)

28. Intel SGX
Анклав (Enclave) – новый компонент вычислительной системы в
процессорах Intel
Анклав представляет собой «перевернутую песочницу» (reversed
sandbox), защищающую содержимое анклава от внешнего
воздействия
Анклав размещается внутри RING3, но ни ядро, ни гипервизор не
имеют доступа к содержимому.
13

29. Intel SGX
Рис. 3: Структура PRM
Элементы анклава размещаются в зарезервированной памяти
(Processor Reserved Memory (PRM)), исключенной из доступной
физической памяти.
PRM разбит на две части [11]: кэш шифрованных страниц (Enclave
Page Cache (EPC)) и конфигурационную таблицу Enclave Page Cache
Map (EPCM) 14

30. Intel SGX
Анклав описывается SGX Enclave Control Structure (SECS)
структурой, хранящейся внутри EPC
• Тип – PT_SECS
• Не могут быть отображены в ОП или прочитаны/изменены
• Работа SECS осуществляется при помощи новых инструкций
• Определяют режим работы и свойства
• Создается через ECREATE
• Уничтожается после удаления SECS из EPC.
15

31. Intel SGX
Thread Control Structure (TCS) – другой тип EPC страниц, описывает
контексты тредов внутри анклава
• TCS описывает размещение в памяти массива структур State
Save Area (SSA)
• SSA хранит контекст треда внутри анклава при обработке
прерывания
• Страницы SSA имеют тип PT_REG и доступны внутри анклава
• Страницы TCS имеют тип PT_TCS и недоступны для прямого
доступа
16

32. Enclave Page Cache (EPC)
Размер PRM ограничен 128 MiB, часть из которых уходят под
структуры
В реальности доступно порядка 92 MiB
EPC работает как кэш, часть страниц выгружены в обычную память
17

33. SGX Анклавы
Рис. 4: Адресное пространство процесса с анклавом
Анклавы размещаются в виртуальном адресном пространстве
пользовательского процесса (Enclave Linear Address
Range (ELRANGE))
Код анклава может иметь доступ к адресному пространству своего
анклава и всем данным/коду процесса, за исключением других
анклавов 18

34. SGX Анклавы
Рис. 5: Адресное пространство процесса с анклавом
Не доверенный код, в свою очередь, имеет доступ только к не
доверенной части, и не может читать/писать/исполнять память
анклавов
Код анклава может иметь доступ к адресному пространству своего
анклава и всем данным/коду процесса, за исключением других
анклавов 19

35. SGX Анклавы
Рис. 6: Адресное пространство процесса с анклавом
Page Table Entries описывающие отображение физических страниц в
виртуальное адресное пространство так же контролируют
отображение страниц EPC, но, в отличие от обычных страниц,
страницы EPC не могут быть пере отображены на новые
виртуальные адреса.
20

36. Жизненный цикл Анклавов
Анклав создается при помощи новой инструкции ECREATE
После создания анклав должен быть наполнен страницами при
помощи инструкции EADD
Страниц могут быть добавлены в анклав только пока контекст
анклава SECS находится в состоянии uninitialized
Инструкция EINIT завершает инициализацию анклава
В дальнейшем страницы EPC могут быть вытеснены и захвачены
при помощи инструкций ELDU/ELDB.
Внутри анклава остается контрольная сумма страницы, для
предотвращения атак «повторного воспроизведения» (replay attack)
21

37. Особенности Анклавов

38. Жизненный цикл Анклавов
Intel предоставляет доступ к SDK для программирования анклавов
Исходный код – доверенные и не доверенный
Взаимодействие между компонентами через специальные вызовы
ECalls и OCalls. Привилегированные операции (например, системный
вызов) запрещены
Минимальный функционал: описание интерфейсов, ограничения по
используемой памяти, скрипты генерации и запуска образов анклава
22

39. Жизненный цикл Анклавов
Анклавы распространяются в зашифрованном виде, расшифровать
их можно только на определенной платформе.
Intel анонсировала поддержку удаленной аттестации через свои
доверенные сервера
ПО анклавов имеет доступ к специализированным функциям:
«запечатывание» (sealing/unsealing), ASN-NI инструкции,
примитивы IPP библиотеки
23

40. Взаимодействие с анклавом
ECalls используются для передачи управления в анклав
OCalls используются внутри анклава для передачи управления в не
доверенную среду
Количество исполняемых ECalls ограничено количеством записей
TCS
При выполнении OCalls контекст потока сохраняется внутри анклава
ECalls и OCalls являются тяжеловесными операциями, требующим от
8200-17000 циклов (против 150 для обычных системных вызовов)
для выполнения [28, 40]
24

41. Пейджинг Анклавов
0 50 100 150 200 250
0
200
400
600
800
92
244.8
memsetperf.
0
50
100
%
Размер активно доступной памяти – 92 MiB
При достижении границы начинает работать тяжеловесный
пейджинг, приводящий к падению производительности не меньше
чем в 2.8 раз 25

42. Обзор SGX работ

43. Перенос легаси кода в SGX
Проблема: код анклавов самостоятелен, изолирован, не может
использовать существующие системные примитивы. Как переносить
легаси код в новое окружение? 4 ключевых работы отвечают на это
вопрос:
Haven [3]
SCONE [2]
PANOPLY [35]
Graphene-SGX [10]
26

44. Haven
Shielding applications from an untrusted cloud with haven
Авторы: Baumann, Andrew, Marcus Peinado, and Galen Hunt.
Одна из самых первых работ про SGX
Ключевые идеи:
• тяжеловесные анклавы
27

45. Haven
Shielding applications from an untrusted cloud with haven
Авторы: Baumann, Andrew, Marcus Peinado, and Galen Hunt.
Одна из самых первых работ про SGX
Ключевые идеи:
• тяжеловесные анклавы
• libos прослойка реализующая множество системных вызовов
27

46. Haven
Shielding applications from an untrusted cloud with haven
Авторы: Baumann, Andrew, Marcus Peinado, and Galen Hunt.
Одна из самых первых работ про SGX
Ключевые идеи:
• тяжеловесные анклавы
• libos прослойка реализующая множество системных вызовов
• shield окружение для контроля возвращаемых в анклав значений
27

47. Scone
Scone: Secure linux containers with intel sgx
Авторы: Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth,
and Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran,
Dan O´Keeffe, and Mark L Stillwell, David Goltzsche, Dave Eyers,
Ruediger Kapitza, Peter Pietzuch, Christof Fetzer
Одна из самых популярных работ по SGX
Основные идеи:
• легковесные анклавы с user-space level threading
PANOPLY [35], так же как и SCONE, виртуализирует слой
операционной системы, но ориентирован на запуск существующих
приложений, а не контейнеров.
28

48. Scone
Scone: Secure linux containers with intel sgx
Авторы: Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth,
and Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran,
Dan O´Keeffe, and Mark L Stillwell, David Goltzsche, Dave Eyers,
Ruediger Kapitza, Peter Pietzuch, Christof Fetzer
Одна из самых популярных работ по SGX
Основные идеи:
• легковесные анклавы с user-space level threading
• вместо синхронных системных вызовов используются
асинхронный обмен данных при помощи атомарных очередей [1]
PANOPLY [35], так же как и SCONE, виртуализирует слой
операционной системы, но ориентирован на запуск существующих
приложений, а не контейнеров.
28

49. Scone
Scone: Secure linux containers with intel sgx
Авторы: Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth,
and Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran,
Dan O´Keeffe, and Mark L Stillwell, David Goltzsche, Dave Eyers,
Ruediger Kapitza, Peter Pietzuch, Christof Fetzer
Одна из самых популярных работ по SGX
Основные идеи:
• легковесные анклавы с user-space level threading
• вместо синхронных системных вызовов используются
асинхронный обмен данных при помощи атомарных очередей [1]
• muslibc реализует минимальный набор системных вызовов
PANOPLY [35], так же как и SCONE, виртуализирует слой
операционной системы, но ориентирован на запуск существующих
приложений, а не контейнеров.
28

50. Graphene-SGX
Graphene-SGX: A practical library OS for unmodified applications
on SGX
Авторы: Tsai, Chia-Che, Donald E. Porter, and Mona Vij
«Сбалансированный» подход
Основные идеи:
• Умеренный размер TCB
29

51. Graphene-SGX
Graphene-SGX: A practical library OS for unmodified applications
on SGX
Авторы: Tsai, Chia-Che, Donald E. Porter, and Mona Vij
«Сбалансированный» подход
Основные идеи:
• Умеренный размер TCB
• Количество ECalls не приводит к существенной деградации
производительности
29

52. SGX специфика
Атомарные очереди FFQ [1]
Eleos [28] – реализация эффективного пейджинга внутри анклавов
без подключения к этой работе драйвера SGX
SGXBOUNDS [24] – защита памяти внутри анклава, программный
аналог Intel MPX
Lightweight Collective Memory (LCM) [6] расширение для SGX
защищающая вытесняемые на носитель данные
Hotcalls [40] интерфейс синхронизации на подобии спинлоков
Glamdring [25] – фреймворк для партишенинга доверенных сервисов
поверх SGX
миграция анклавов [18]
Попытки разработки ASLR [9]
30

53. Применение анклавов
Privacy preserving cloud computing – облачные вычисления с
сохранением конфиденциальности
VC3 [32] – защищенный Map-reduce
Ryoan [23] – NaCl «песочница» с использованием SGX
SCBR [30] – распределенный роутинг сообщений между множеством
анклавов
SecureKeeper [8] – Распределенный KVS поверх zookeper
Hybster [4] – использование SGX в консенсус протоколах
И многое другое...
31

54. Атаки на SGX
Анклавы используют часть компонентов вычислительной системы,
как и небезопасный код. Как следствие анклавы уязвимы к
side-channel атакам
Prime+Probe атака выполненная внутри зараженного анклава
позволяет восстановить RSA ключи из другого анклава [33, 7]
манипулируя с PTE можно восстановить путь исполнения внутри
анклава [38]
Update 2018: SGX уязвим к Spectre
32

55. Перспективы SGX
Client-side SGX
• DRM
• анализ и шифрование трафика
• компиляция css/jss кода [15]
• . . .
33

56. AMD Secure Memory
Encryption (SME)

57. AMD SME
AMD Secure Memory Encryption (SME) – новое расширение
процессоров AMD
• Прозрачное шифрование «на лету» контроллером памяти
• Радикально отличается от Intel SGX
34

58. AMD SME
Memo
AES
write
1
C-bitMemory
C-bit
AES
read
1
AES
Virtual Physical
Memory
AES
write
1
C-bit
Memory
C-bit
AES
read
1
AES
Virtual Physical
• каждая страница памяти получает новый бит в TLB записи –
бит шифрования
35

59. AMD SME
Memo
AES
write
1
C-bitMemory
C-bit
AES
read
1
AES
Virtual Physical
Memory
AES
write
1
C-bit
Memory
C-bit
AES
read
1
AES
Virtual Physical
• каждая страница памяти получает новый бит в TLB записи –
бит шифрования
• В зависимости от значения C бита (номер 47), при чтении
данные расшифровываются, а при записи шифруются
35

60. AMD SME
Memo
AES
write
1
C-bitMemory
C-bit
AES
read
1
AES
Virtual Physical
Memory
AES
write
1
C-bit
Memory
C-bit
AES
read
1
AES
Virtual Physical
• каждая страница памяти получает новый бит в TLB записи –
бит шифрования
• В зависимости от значения C бита (номер 47), при чтении
данные расшифровываются, а при записи шифруются
• Одна и та же физическая страница может быть отображена в
разные виртуальные адреса разными PTE, и может быть
доступна в обеих формах
35

61. AMD SME
C-bit
AES
1
AES
Virtual Physical
• Одна и та же физическая страница может быть отображена в
разные виртуальные адреса разными PTE, а значит может
присутствовать в двух состояниях одновременно
36

62. AMD SME
C-bit
AES
1
AES
Virtual Physical
• Одна и та же физическая страница может быть отображена в
разные виртуальные адреса разными PTE, а значит может
присутствовать в двух состояниях одновременно
• Копирование из одного виртуального адреса в другой приводит
к перешифрованию «на лету»
36

63. AMD SME
C-bit
AES
1
AES
Virtual Physical
• Одна и та же физическая страница может быть отображена в
разные виртуальные адреса разными PTE, а значит может
присутствовать в двух состояниях одновременно
• Копирование из одного виртуального адреса в другой приводит
к перешифрованию «на лету»
• In-pace encryption чувствительно к политике кэширования
36

64. AMD SME
• Шифрование памяти прозрачно для DMA устройств
37

65. AMD SME
• Шифрование памяти прозрачно для DMA устройств
• Модификация C бита требует сброса кэшей и приводит к
«трансформации» хранимых данных
37

66. AMD SME
• Шифрование памяти прозрачно для DMA устройств
• Модификация C бита требует сброса кэшей и приводит к
«трансформации» хранимых данных
• Минимальная поддержка AMD SME добавлена в ядро 4.14
37

67. AMD SME
• Шифрование памяти прозрачно для DMA устройств
• Модификация C бита требует сброса кэшей и приводит к
«трансформации» хранимых данных
• Минимальная поддержка AMD SME добавлена в ядро 4.14
• Transparent SME (TSME)
37

68. Тесты производительности
• Доступ к шифрованной и не шифрованной памяти практически
одинаков (3627 MiB/s)
38

69. Тесты производительности
• Доступ к шифрованной и не шифрованной памяти практически
одинаков (3627 MiB/s)
• RAM Drive в шифрованной памяти быстрее AES-NI crypto loop в
2 раза (2491 vs 1218 MiB/s)
38

70. Тесты производительности
• Доступ к шифрованной и не шифрованной памяти практически
одинаков (3627 MiB/s)
• RAM Drive в шифрованной памяти быстрее AES-NI crypto loop в
2 раза (2491 vs 1218 MiB/s)
• Transparent SME (TSME)
38

71. Особенности реализации
• Ключ шифрования генерируется каждый раз новый после
каждой перезагрузки
39

72. Особенности реализации
• Ключ шифрования генерируется каждый раз новый после
каждой перезагрузки
• Четные и нечетные страницы имеют одинаковый шифротекст
для одних и тех же данных, но разный в каждой паре
39

73. Особенности реализации
• Ключ шифрования генерируется каждый раз новый после
каждой перезагрузки
• Четные и нечетные страницы имеют одинаковый шифротекст
для одних и тех же данных, но разный в каждой паре
• XOR с шифротекста показывает один и тот же набор значений
(Например, 77 d9 10 77 77 d9 10 77 77 d9 10 77 77 d9 10 77)
39

74. Особенности реализации
• Ключ шифрования генерируется каждый раз новый после
каждой перезагрузки
• Четные и нечетные страницы имеют одинаковый шифротекст
для одних и тех же данных, но разный в каждой паре
• XOR с шифротекста показывает один и тот же набор значений
(Например, 77 d9 10 77 77 d9 10 77 77 d9 10 77 77 d9 10 77)
• Данные можно восстановить только с тех виртуальных адресов,
где они были ранее размещены 39

75. AMD Secure Encrypted
Virtualization (SEV)

76. AMD Secure Encrypted Virtualization (SEV)
AMD SEV – расширение AMD SoC позволяющее исполнять
зашифрованные виртуальные машины
Ключевые отличия от SME:
• Каждая VM имеет свой собственный ключ шифрования
• DMA устройства не имеют доступа к памяти VM
Особенности SEV:
• И гипервизор и виртуальные машины могут быть зашифрованы
одновременно разными ключами
• Взаимодействие между ними осуществляется через
специальную память, которая шифруется ключом гипервизора
• Поддержка SEV реализуется в том числе при помощи нового
ядра ARM внутри SoC, осуществляющего контроль и управление
виртуальных машин, а также их миграцию
40

77. Спасибо
40

78. References i
S. Arnautov, P. Felber, C. Fetzer, and B. Trach.
Ffq: A fast single-producer/multiple-consumer concurrent fifo
queue.
In Parallel and Distributed Processing Symposium (IPDPS), 2017
IEEE International, pages 907–916. IEEE, 2017.
S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe,
J. Lind, D. Muthukumaran, D. O’Keeffe, M. Stillwell, et al.
Scone: Secure linux containers with intel sgx.
In OSDI, pages 689–703, 2016.
A. Baumann, M. Peinado, and G. Hunt.
Shielding applications from an untrusted cloud with haven.
ACM Transactions on Computer Systems (TOCS), 33(3):8, 2015.

79. References ii
J. Behl, T. Distler, and R. Kapitza.
Hybrids on steroids: Sgx-based high performance bft.
In Proceedings of the Twelfth European Conference on Computer
Systems, pages 222–237. ACM, 2017.
E.-O. Blass and W. Robertson.
Tresor-hunt: attacking cpu-bound encryption.
In Proceedings of the 28th Annual Computer Security Applications
Conference, pages 71–78. ACM, 2012.
M. Brandenburger, C. Cachin, M. Lorenz, and R. Kapitza.
Rollback and forking detection for trusted execution
environments using lightweight collective memory.
In Proceedings of the 47th International Conference on Dependable
Systems and Networks, DSN’17, 2017.

80. References iii
F. Brasser, U. M¨uller, A. Dmitrienko, K. Kostiainen, S. Capkun, and
A.-R. Sadeghi.
Software grand exposure: Sgx cache attacks are practical.
arXiv preprint arXiv:1702.07521, 2017.
S. Brenner, C. Wulf, D. Goltzsche, N. Weichbrodt, M. Lorenz,
C. Fetzer, P. R. Pietzuch, and R. Kapitza.
Securekeeper: Confidential zookeeper using intel sgx.
In Middleware, page 14, 2016.
S. Chandra, V. Karande, Z. Lin, L. Khan, M. Kantarcioglu, and
B. Thuraisingham.
Securing data analytics on sgx with randomization.
In European Symposium on Research in Computer Security, pages
352–369. Springer, 2017.

81. References iv
C. che Tsai, D. E. Porter, and M. Vij.
Graphene-sgx: A practical library OS for unmodified
applications on SGX.
In 2017 USENIX Annual Technical Conference (USENIX ATC 17),
pages 645–658, Santa Clara, CA, 2017. USENIX Association.
V. Costan and S. Devadas.
Intel sgx explained.
IACR Cryptology ePrint Archive, 2016:86, 2016.
G. Duc and R. Keryell.
Cryptopage: An efficient secure architecture with memory
encryption, integrity and information leakage protection.
In Computer Security Applications Conference, 2006. ACSAC’06.
22nd Annual, pages 483–492. IEEE, 2006.

82. References v
S. Ferede Yitbarek, M. Tadesse Aga, R. Das, and T. Austin.
Cold boot attacks are still hot: Security analysis of memory
scramblers in modern processors.
IEEE Symposium on High Performance Computer Architecture
(HPCA), 2017.
B. Garmany and T. M¨uller.
Prime: private rsa infrastructure for memory-less encryption.
In Proceedings of the 29th Annual Computer Security Applications
Conference, pages 149–158. ACM, 2013.
D. Goltzsche, C. Wulf, D. Muthukumaran, K. Rieck, P. Pietzuch,
and R. Kapitza.
Trustjs: Trusted client-side execution of javascript.
In Proceedings of the 10th European Workshop on Systems Security,
page 7. ACM, 2017.

83. References vi
J. Gotzfried and T. Muller.
Armored: cpu-bound encryption for android-driven arm
devices.
In Availability, Reliability and Security (ARES), 2013 Eighth
International Conference on, pages 161–168. IEEE, 2013.
J. G¨otzfried, T. M¨uller, G. Drescher, S. N¨urnberger, and M. Backes.
Ramcrypt: Kernel-based address space encryption for
user-mode processes.
In Proceedings of the 11th ACM on Asia Conference on Computer
and Communications Security, pages 919–924. ACM, 2016.
J. Gu, Z. Hua, Y. Xia, H. Chen, B. Zang, H. Guan, and J. Li.
Secure live migration of sgx enclaves on untrusted cloud.
In Dependable Systems and Networks (DSN), 2017 47th Annual
IEEE/IFIP International Conference on, pages 225–236. IEEE, 2017.

84. References vii
L. Guan, J. Lin, B. Luo, and J. Jing.
Copker: Computing with private keys without ram.
In NDSS, pages 23–26, 2014.
L. Guan, J. Lin, B. Luo, J. Jing, and J. Wang.
Protecting private keys against memory disclosure attacks
using hardware transactional memory.
In Security and Privacy (SP), 2015 IEEE Symposium on, pages
3–19. IEEE, 2015.
J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul,
J. A. Calandrino, A. J. Feldman, J. Appelbaum, and E. W. Felten.
Lest we remember: cold-boot attacks on encryption keys.
Communications of the ACM, 52(5):91–98, 2009.

85. References viii
M. Henson and S. Taylor.
Memory encryption: a survey of existing techniques.
ACM Computing Surveys (CSUR), 46(4):53, 2014.
T. Hunt, Z. Zhu, Y. Xu, S. Peter, and E. Witchel.
Ryoan: A distributed sandbox for untrusted computation on
secret data.
In OSDI, pages 533–549, 2016.
D. Kuvaiskii, O. Oleksenko, S. Arnautov, B. Trach, P. Bhatotia,
P. Felber, and C. Fetzer.
Sgxbounds: Memory safety for shielded execution.
In Proceedings of the Twelfth European Conference on Computer
Systems, pages 205–221. ACM, 2017.

86. References ix
J. Lind, C. Priebe, D. Muthukumaran, D. O’Keeffe, P.-L. Aublin,
F. Kelbert, T. Reiher, D. Goltzsche, D. Eyers, R. Kapitza, et al.
Glamdring: Automatic application partitioning for intel sgx.
In Proceedings of the USENIX Annual Technical Conference (ATC),
page 24, 2017.
T. M¨uller, F. C. Freiling, and A. Dewald.
Tresor runs encryption securely outside ram.
In USENIX Security Symposium, volume 17, 2011.
T. M¨uller, B. Taubmann, and F. C. Freiling.
Trevisor.
In International Conference on Applied Cryptography and Network
Security, pages 66–83. Springer, 2012.

87. References x
M. Orenbach, P. Lifshits, M. Minkin, and M. Silberstein.
Eleos: Exitless os services for sgx enclaves.
In EuroSys, pages 238–253, 2017.
P. A. Peterson.
Cryptkeeper: Improving security with encrypted ram.
In Technologies for Homeland Security (HST), 2010 IEEE
International Conference on, pages 120–126. IEEE, 2010.
R. Pires, M. Pasin, P. Felber, and C. Fetzer.
Secure content-based routing using intel software guard
extensions.
In Proceedings of the 17th International Middleware Conference,
page 10. ACM, 2016.

88. References xi
B. Rogers, S. Chhabra, M. Prvulovic, and Y. Solihin.
Using address independent seed encryption and bonsai merkle
trees to make secure processors os-and performance-friendly.
In Microarchitecture, 2007. MICRO 2007. 40th Annual IEEE/ACM
International Symposium on, pages 183–196. IEEE, 2007.
F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado,
G. Mainar-Ruiz, and M. Russinovich.
Vc3: Trustworthy data analytics in the cloud using sgx.
In Security and Privacy (SP), 2015 IEEE Symposium on, pages
38–54. IEEE, 2015.
M. Schwarz, S. Weiser, D. Gruss, C. Maurice, and S. Mangard.
Malware guard extension: Using sgx to conceal cache attacks.
arXiv preprint arXiv:1702.08719, 2017.

89. References xii
T. Shinagawa, H. Eiraku, K. Tanimoto, K. Omote, S. Hasegawa,
T. Horie, M. Hirano, K. Kourai, Y. Oyama, E. Kawai, et al.
Bitvisor: a thin hypervisor for enforcing i/o device security.
In Proceedings of the 2009 ACM SIGPLAN/SIGOPS international
conference on Virtual execution environments, pages 121–130. ACM,
2009.
S. Shinde, D. Le Tien, S. Tople, and P. Saxena.
Panoply: Low-tcb linux applications with sgx enclaves.
In Proc. of the Annual Network and Distributed System Security
Symp.(NDSS), 2017.

90. References xiii
P. Simmons.
Security through amnesia: a software-based solution to the
cold boot attack on disk encryption.
In Proceedings of the 27th Annual Computer Security Applications
Conference, pages 73–82. ACM, 2011.
G. E. Suh, C. W. O’Donnell, and S. Devadas.
Aegis: A single-chip secure processor.
IEEE Design & Test of Computers, 24(6), 2007.
J. Van Bulck, N. Weichbrodt, R. Kapitza, F. Piessens, and
R. Strackx.
Telling your secrets without page faults: Stealthy page
table-based attacks on enclaved execution.
In Proceedings of the 26th USENIX Security Symposium. USENIX
Association, 2017.

91. References xiv
G. Vasiliadis, E. Athanasopoulos, M. Polychronakis, and S. Ioannidis.
Pixelvault: Using gpus for securing cryptographic operations.
In Proceedings of the 2014 ACM SIGSAC Conference on Computer
and Communications Security, pages 1131–1142. ACM, 2014.
O. Weisse, V. Bertacco, and T. Austin.
Regaining lost cycles with hotcalls: A fast interface for sgx
secure enclaves.
In Proceedings of the 44th Annual International Symposium on
Computer Architecture, pages 81–93. ACM, 2017.