Архитектура FaaS и проверяемая честность для систем машинного обучения
4 января 2024 г.:::информация Этот документ доступен на arxiv по лицензии CC BY 4.0 DEED.
Авторы:
(1) Эхсан Торейни, Университет Суррея, Великобритания;
(2) Марьям Мехрнежад, Лондонский университет Ройал Холлоуэй;
(3) Аад Ван Мурсел, Бирмингемский университет.
:::
Таблица ссылок
Справочная информация и сопутствующая работа
Анализ внедрения и производительности
3 Архитектура FaaS
В этом разделе мы представляем архитектуру нашей системы (рис. 1) и описываем ее особенности. Архитектура FaaS включает в себя заинтересованные стороны в трех ролях: A) Система ML: система, которая владеет данными и алгоритмом ML, B) Служба аудита справедливости: служба, которая рассчитывает справедливую производительность системы ML и C) Универсальный верификатор: любой желающий. у которого есть технические знания и мотивация для проверки процесса аудита.
3.1 Модель угроз
Проектирование и реализация безопасности сторон, реализующих соответствующие роли протокола (система ML, служба аудита справедливости и универсальный верификатор) (рис. 1), независимы друг от друга. Взаимосвязь, происходящая между ролями, не предполагает доверия между сторонами; таким образом, все их утверждения должны сопровождаться подтверждающими доказательствами (для которых мы будем использовать ZKP). Мы предполагаем, что система аудита уязвима для различных атак и не заслуживает доверия. Таким образом, данные, хранящиеся в системе аудита справедливости, должны быть зашифрованы, защищены от несанкционированного доступа и поддаются проверке на всех этапах. Более того, мы предполагаем, что канал связи между системой ОД и аудитором справедливости не защищен. Поэтому конфиденциальные данные должны быть зашифрованы до начала передачи. Однако на этапе предварительной настройки в последовательности протокола будет достигнуто соглашение о криптографических примитивах.
В FaaS мы предполагаем, что система ML честно отправляет криптограммы исходных меток образцов набора данных. Можно возразить против такого предположения и обсудить, что система МО может намереваться обмануть Службу аудита и, соответственно, проверяющих, изменяя фактические метки набора данных. Например, система МО будет предоставлять криптограммы реальных и прогнозируемых меток, максимально похожих друг на друга, чтобы аудитор пришел к выводу, что алгоритмы справедливы. Это интересная область для дальнейших исследований. Например, эту проблему можно решить, предоставив криптограммы реальных меток Службе аудита независимо, например. верификатор может владеть набором данных, который он предоставляет системе ML. Затем верификатор отдельно определяет желаемые значения для фактических меток и передает их в службу Auditor. Таким образом, системе ML гораздо менее понятно, как манипулировать данными, которые она отправляет аудитору, поскольку некоторые метки поступают откуда-то еще.
Внутренняя безопасность ролей выходит за рамки FaaS. Сама система ML должна рассмотреть дополнительные меры для защиты своих данных и алгоритмов. Мы предполагаем, что система ML честно представляет данные и прогнозы. Это разумное предположение, поскольку стимулы к соблюдению этических норм противоречат нечестному участию в процессе аудита справедливости. Подробнее это обсуждается в разделе «Обсуждение».
Таблица 2: Возможные варианты 3-битного представления записи в исходных данных.
3.2 Обзор протокола
Основная последовательность протоколов безопасности осуществляется между системой ML и службой аудита справедливости или, вкратце, аудитором. Обратите внимание: хотя мы предлагаем три роли в нашей архитектуре, связь в основном осуществляется между двумя вышеупомянутыми ролями, и любой универсальный верификатор может обратиться к службе аудиторов (которая представляет собой комиссию по справедливости), если они хотят оспорить вычисления.
Система ML отвечает за реализацию и выполнение алгоритма ML. Он имеет данные на входе и выполняет некоторый прогноз (в зависимости от варианта использования и цели), который формирует выходные данные (рис. 1). Служба аудита справедливости получает информацию из системы ML, оценивает ее эффективность путем расчета показателя справедливости. Затем он возвращает результат метрики обратно в систему машинного обучения. Он также публикует расчеты на совете по справедливости для публичной проверки. Общественный совет по справедливости — это общедоступный совет по справедливости, доступный только для чтения (например, веб-сайт). Аудитор имеет право только приложить данные (и достаточные доказательства) к совету по справедливости. Также аудитор проверяет подлинность, правильность и целостность данных перед их публикацией.
3.3 Последовательность протоколов
Этот протокол состоит из трех этапов: настройка, генерация криптограммы и вычисление показателя справедливости.
3.3.1 Этап I: Настройка
На этом этапе система ML и аудитор согласовывают первоначальные настройки. Мы предполагаем, что протокол функционирует в условиях мультипликативной циклической группы (т. е. группы, подобной алгоритму цифровой подписи (DSA) [18]), но он также может функционировать в аддитивных циклических группах (т. е. группах, подобных алгоритму цифровой подписи с эллиптической кривой (ECDSA) [18) ]). Аудитор и система МО публично согласовывают (p, q, g) до начала протокола. Пусть p и q — два больших простых числа, где q|(p − 1). В мультипликативной циклической группе (Z∗ p) Gq — подгруппа простого порядка q, а g — ее образующая. Для простоты мы предполагаем, что проблема решения Диффи-Хеллмана (DDH) выходит за рамки [31].
Затем система ML генерирует пару открытый/закрытый ключ с помощью DSA или ECDSA и публикует открытые ключи на доске справедливости. Защита пары закрытых ключей зависит от архитектуры безопасности системы ML, и мы предполагаем, что закрытый ключ надежно хранится в соответствии с промышленными стандартами (например, с использованием встроенного защищенного модуля памяти).
Таблица криптограмм. После первоначальных соглашений система машинного обучения создает таблицу криптограмм с n строками, соответствующими количеству выборок в их тестовом наборе данных. В оставшейся части статьи мы будем называть эту таблицу таблицей криптограмм. Если система МО не желает раскрывать количество образцов в тестовом наборе, аудитор и система МО могут публично договориться о n. В этом случае n должно быть достаточно большим, чтобы универсальные верификаторы были удовлетворены результатом.
Каждая строка в таблице криптограммы суммирует три параметра: (1) статус членства в защищенной группе, (2) ее фактическая метка и (3) метка, предсказанная моделью ML. Каждая строка содержит зашифрованный формат трех параметров вместе с доказательствами его правильности. Таблица криптограмм на этапе настройки представлена в таблице 3. В простейшем случае каждый параметр является двоичным. Таким образом, объединенные параметры дадут в общей сложности восемь перестановок. На этапе настройки создается таблица, содержащая все восемь возможных перестановок и их доказательства для каждого образца данных. Общая структура перестановок показана в таблице 2. Каждая строка будет удовлетворять четырем свойствам: (а) можно легко проверить, является ли отдельная криптограмма зашифрованной версией одной из восьми возможных перестановок, (б) при этом можно проверить, если только выбрана одна единственная криптограмма, невозможно определить, какие перестановки представляет текущая криптограмма, (c) для каждых двух криптограмм, выбранных из одной строки, любой сможет отличить друг от друга, и (d) при наличии набора криптограмм произвольно выбрать из каждой строки как набора можно легко проверить, сколько случаев для каждой «перестановки» содержится в наборе.
Формирование функций таблицы криптограмм основано на следующей последовательности:
Шаг (1): Для каждого из n образцов система генерирует случайный открытый ключ g xi, где xi — закрытый ключ, а xi ∈ [1, q − 1].
Шаг (3): Соответствующий номер столбца, равный десятичному значению двоичной кодировки, выбирается из таблицы криптограммы для заполнения таблицы аудита справедливости (как показано в таблице 2).
Наконец, созданная таблица аудита справедливости имеет цифровую подпись в системе ML, а затем отправляется через службу аудита справедливости.
3.3.3 Этап III: Оценка справедливости
Сначала служба аудита справедливости получает таблицу аудита справедливости, проверяет цифровую подпись и ZKP и публикует содержимое на доске справедливости.
На этом этапе мы расширяем каждый из этих компонентов уравнения, чтобы сравнить их вместе.
Этот процесс требует больших вычислительных ресурсов, особенно если количество выборок данных в таблице аудита справедливости велико. В этом случае аудитор справедливости может делегировать объявление номера перестановки системе ML. Аудитор по-прежнему получает таблицу аудита справедливости и соответствующие ZKP. Он может сохранять таблицу аудита справедливости на плате справедливости, вычислять справедливость и проверять правильность объявленных чисел перестановок. Универсальный верификатор может выполнить те же действия для проверки расчетов показателей справедливости с помощью таблицы аудита справедливости, которая общедоступна через доску справедливости.
В конце этого этапа аудитор использует полученные данные для расчета показателя справедливости и публикует информацию. Количество каждой перестановки обозначает общую производительность алгоритма ML для каждой из групп с защищенным атрибутом. В Таблице 4 показаны варианты и то, как они связаны с показателем справедливости системы МО. Таблица криптограммы и результаты будут опубликованы на доске честности (рис. 1)
Оригинал