Это второй пост в нашей серии о проверяемо безопасных вычислениях, начало в статье о проверках прокси.

Задача

Принцип минимизации данных гласит, что только необходимые данные должны собираться для каждой конкретной бизнес-цели. Минимизация данных является краеугольным камнем обеспечения конфиденциальности в сети: невозможно продать, потерять или воспользоваться не по назначению тем, чего у вас попросту нет. Однако же иногда необходимо обработать чувствительные данные, а криптографические кирпичики типа многостороннего конфиденциального вычисления или гомоморфного шифрования могут для нужной задачи не подходить. Рассмотрим простой пример: допустим, Brave хочет поздравлять вас с днём рождения раз в году. Большинство компаний реализуют такую функцию следующим образом: они записывают дату рождения каждого пользователя в базу данных, а затем проверяют её каждый день и рассылают поздравительные письма всем, у кого в этот день праздник. Но эта дата является чувствительной информацией. Как правильно, нет никаких значимых причин, по которым компаниям (или рекламодателям) надо знать дату вашего рождения, особенно учитывая риски потенциальных утечек.

Как нам построить такой сервис без знания вашей даты рождения? И вообще, как мы можем построить любой сервис, обрабатывающий конфиденциальные данные, без того, чтобы видеть эти данные? Чтобы ответить на этот вопрос, давайте познакомимся с технологией безопасных анклавов

Безопасные анклавы

Безопасные анклавы позволяют вашему компьютеру обработать информацию изолированно от других программ и данных. Операционная система — это надёжный фундамент компьютера, предоставляющий приложениям типа Brave среду для функционирования. Если в ОС появляется дыра в безопасности, все данные на компьютере теперь в опасности. Безопасный анклав помогает сгладить эту проблему. О нём можно думать как об изолированном крошечном компьютере внутри компьютера. Даже если основной компьютер взломан, безопасный анклав не будет затронут, и ему можно будет продолжать доверять. 

Многие производители процессоров предлагают подобные безопасные анклавы как для серверов, так и для домашних ПК. Так, у Intel есть Trust Domain Extensions и SGX, у ARM — TrustZone, а у AMD — SEV. Многие компании используют технологию анклавов в самых разных целях: например, Signal использует эту технологию для конфиденциального поиска контактов, Apple для Face ID, а другие для защиты копирайта и блокчейн-технологий. Ну а мы можем использовать эту технологию для конфиденциальных поздравлений с днём рождения.

Для демонстрации этого мы вдохновились новым типом безопасных анклавов, который был представлен Amazon в 2020 году под названием AWS Nitro Enclaves. Мы выбрали именно эту технологию, так как она представляет собой виртуальные машины, которые не имеют общих ресурсов с другими виртуальными машинами. Это устраняет целый класс багов, от которых годами страдала SGX, а именно преслувутою атаку по сторонним каналам. Если быть более точными, мы разработали бесплатный инструмент nitriding, который позволяет запускать сетевые приложения внутри Nitro Enclave, и при этом часто без каких-либо модификаций. Nitriding позволяет нам запускать наш конфиденциальный сервис поздравлений внутри анклава. Тем не менее, мы должны рассмотреть возможность трёх атак:

  1. Что если Brave задумала эксфильтрацию данных о дате рождения?

  2. Что если Brave заявляет, что исполняет одну версию кода, а на деле тайно исполняет другую?

  3. Что если Brave хочет перехватить даты рождения на их пути в анклав?

Атака 1: Эксфильтрация данных

Что останавливает Brave от того, чтобы залогиниться в безопасный анклав и заполучить все даты рождения из его памяти? Такая атака предотвращается самим дизайном Nitro Enclaves. Несмотря на то, что Brave написала код, который исполняется внутри анклава, ни мы, ни Amazon (и вообще никто) не можем наблюдать за кодом и его данными в момент исполнения. Это означает, что мы не можем видеть данные, которые попадают в анклав, и вычисления, проходящие внутри него. Мы не можем залогиниться в Nitro Enclave — по сути, это запаянный чёрный ящик. Когда данные (о днях рождения) попадают в анклав, они защищены.

Атака 2: Тайное исполнение вредоносного кода

Добросовестный и зловредный коды на картинке ниже практически идентичны, но зловредный код содержит выделенную красным функцию, которая сливает данные дня рождения. Что остановит Brave от того, чтобы заявить, что мы исполняем добросовестный код, но вместо этого запускать зловредный?

Слева: добросовестный код. Справа: вредоносный код.
Слева: добросовестный код. Справа: вредоносный код.

Эта атака предотвращается другой особенностью Nitro Enclaves под названием «удалённая аттестация»‎. Пользователи могут по сети проверить и убедиться, что мы действительно исполняем именно тот код, который заявили. Если бы мы тайно запустили другой код, наши пользователи это заметили бы благодаря криптографическому процессу аттестации, встроенному в Nitro (мы расскажем об удалённой аттестации в отдельном посте).

Атака 3: Перехват данных

Хорошо, мы не можем ни организовать эксфильтрацию данных из памяти анклава, ни тайный запуск зловредного кода. Но что остановит нас от перехвата дней рождений в тот момент, когда они передаются в анклав?

Эта атака также предотвращается нашим инструментом nitriding. Nitriding подсвечивает Web-сервис, запущенный внутри анклава, и криптографически привязывает HTTPS-сертификат Web-сервиса к аттестационному документу, который выдаётся самой системой Nitro. Это позволяет пользователям проверить и убедиться, что они разговаривают напрямую с анклавом без участия каких-либо посредников. Другими словами, Brave (или любая другая третья сторона) сможет заполучить валидный HTTPS-сертификат для анклава, но не сможет ссылаться на этот зловредный сертификат в документе аттестации, который является корнем доверия. У пользователя есть криптографическая гарантия, обеспеченная его клиентом, что он общается лишь с анклавом и ни с кем больше. 

А что насчёт недостатков?

Подытожим: если Алиса хочет получать поздравления с днём рожденья от Brave, сначала она проводит аудит исходного кода сервиса поздравлений, чтобы убедиться, что код надёжен и безопасен. Затем Алиса устанавливает TLS-соединение с приложением анклава и удостоверяется, что оно исполняет именно тот код, который только что был проверен. Теперь Алиса может раскрыть дату своего рождения приложению в анклаве, потому что она знает, что эти данные будут в безопасности. Именно таким образом Brave строит системы на основе проверяемо конфиденциального вычисления.

Тем не менее, Nitro Enclaves — это не панацея от всех бед. Мы считаем, что их дизайн более надёжен и гибок по сравнению с SGX от Intel, но это новая технология. Ей ещё только предстоит пройти испытание временем и быть всесторонне исследованной специалистами по безопасности. Другая её проблема заключается в том, что Nitro Enclaves — проприетарная технология. AWS опубликовали её архитектуру, но сам дизайн на уровне железа (и части софта) остаётся проприетарным, что вынуждает нас обладать определённой долей доверия к Amazon. Это достаточно стандартная практика для многих дизайнов анклавов, но при этом всё равно проблематичная, так как закрытые железо и софт не могут быть легко проверены третьими сторонами.

Учитывая эти ограничения, мы решили не класть все яйца в одну корзину и с осторожностью продвигаться вперёд с применением анклавных приложений. Одним из применений этой технологии станет сервис, важный для нашей системы конфиденциальной продуктовой аналитики (P3A), о котором речь пойдёт в следующей статье. 

Комментарии (0)