Arquitectura FaaS y equidad verificable para sistemas de aprendizaje automático

Tabla de enlaces

Resumen e introducción

Antecedentes y trabajos relacionados

Arquitectura FaaS

Análisis de implementación y desempeño

Conclusión

Reconocimientos y Referencias

3 Arquitectura FaaS

En esta sección, presentamos la arquitectura de nuestro sistema (Fig. 1) y describimos sus características. La arquitectura FaaS incluye partes interesadas en tres roles: A) Sistema de ML: un sistema que posee los datos y el algoritmo de ML, B) Servicio de Auditor de Equidad: un servicio que calcula el desempeño justo del sistema de ML, y C) Verificador Universal: cualquier persona que tenga la experiencia técnica y la motivación para verificar el proceso de auditoría.

3.1 Modelo de amenaza

El diseño y la implementación de la seguridad de las partes que implementan las respectivas funciones del protocolo (sistema ML, Servicio de Auditor de Equidad y Verificador Universal) (Fig. 1) son independientes entre sí. Las intercomunicaciones que ocurren entre los roles suponen que no hay confianza entre las partes; por lo tanto, todas sus afirmaciones deben ir acompañadas de pruebas de validación (para las cuales utilizaremos ZKP). Asumimos que el Auditor System es vulnerable a diferentes ataques y no es confiable. Por lo tanto, los datos almacenados en el Fairness Auditor System deben estar cifrados, ser a prueba de manipulaciones y ser verificables en todas las etapas. Además, asumimos que el canal de comunicación entre el sistema de ML y el auditor de equidad no está protegido. Por lo tanto, los datos confidenciales deben cifrarse antes de que comience la transmisión. Sin embargo, habrá un acuerdo sobre las primitivas criptográficas en la etapa de preestablecimiento de la secuencia del protocolo.

En FaaS, asumimos que el sistema ML es honesto al enviar los criptogramas de las etiquetas originales de las muestras del conjunto de datos. Se podría argumentar en contra de tal suposición y discutir que el sistema ML podría intentar engañar al Servicio de Auditoría y, por extensión, a los verificadores, modificando las etiquetas reales del conjunto de datos. Por ejemplo, el sistema ML proporcionaría los criptogramas de las etiquetas reales y los predichos lo más similares posible entre sí para que el auditor concluya que los algoritmos son justos. Esta es un área interesante para futuras investigaciones. Por ejemplo, se puede abordar proporcionando los criptogramas de las etiquetas reales al Servicio de Auditoría de forma independiente; por ejemplo, el verificador puede poseer un conjunto de datos que proporciona a un sistema de ML. Luego, el verificador decide por separado los valores deseados para las etiquetas reales y los envía al servicio Auditor. De esta manera, al sistema de ML le resulta mucho menos claro cómo manipular los datos que envía al auditor, ya que algunas de las etiquetas provienen de otra parte.

La seguridad interna de los roles va más allá de FaaS. El propio sistema de ML debe considerar medidas adicionales para proteger sus datos y algoritmos. Asumimos que el sistema ML presenta los datos y las predicciones de manera honesta. Esta es una suposición razonable ya que los incentivos para desempeñarse éticamente contrastan con ser deshonesto al participar en un proceso de auditoría de equidad. Esto se analiza más en la Sección de Discusión.

Tabla 2: Posibles permutaciones de representación de 3 bits de una entrada en los datos originales.

3.2 Descripción general del protocolo

La secuencia principal del protocolo de seguridad es entre el sistema ML y el Servicio de Auditoría de Equidad o auditor en forma abreviada. Tenga en cuenta que, aunque sugerimos tres roles en nuestra arquitectura, las comunicaciones se realizan principalmente entre los dos roles anteriores, y cualquier verificador universal puede recurrir al servicio de auditor (que representa la junta de equidad) si quiere cuestionar los cálculos.

El sistema ML es responsable de la implementación y ejecución del algoritmo ML. Tiene datos como entrada y realiza alguna predicción (según el caso de uso y el propósito) que forma la salida (Fig. 1). El Servicio de Auditor de Equidad recibe información del sistema ML y evalúa su desempeño de equidad calculando una métrica de equidad. Luego, devuelve el resultado de la métrica al sistema ML. También publica los cálculos en un comité de equidad para su verificación pública. El consejo de equidad pública es un tablero de equidad de sólo lectura y de acceso público (por ejemplo, un sitio web). El auditor sólo tiene derecho a adjuntar datos (y pruebas suficientes) al consejo de equidad. Además, el auditor verifica la autenticidad, corrección e integridad de los datos antes de publicarlos.

3.3 Secuencia del protocolo

Este protocolo tiene tres etapas: configuración, generación de criptogramas y cálculo de métricas de equidad.

3.3.1 Fase I: Configuración

En esta fase, el sistema ML y el auditor acuerdan la configuración inicial. Asumimos que el protocolo funciona en una configuración de grupo cíclico multiplicativo (es decir, un grupo similar al Algoritmo de firma digital (DSA) [18]), pero también puede funcionar en grupos cíclicos aditivos (es decir, grupos similares al Algoritmo de firma digital de curva elíptica (ECDSA) [18 ]). El auditor y el sistema de ML acuerdan públicamente (p, q, g) antes del inicio del protocolo. Sean p y q dos grandes primos donde q|(p − 1). En un grupo cíclico multiplicativo (Z ∗ p), Gq es un subgrupo de orden primo q y g es su generador. Para simplificar, asumimos que el problema de Decisión Diffie-Hellman (DDH) está fuera de alcance [31].

A continuación, el sistema ML genera un par de claves pública/privada mediante DSA o ECDSA y publica las claves públicas en el tablero de equidad. La protección del par de claves privadas depende de la arquitectura de seguridad del sistema ML y asumimos que la clave privada se almacena de forma segura según una práctica estándar industrial (por ejemplo, utilizando el módulo de memoria seguro integrado).

Tabla de criptogramas: después de los acuerdos iniciales, el sistema ML produce una tabla de criptogramas con n filas correspondientes al número de muestras en su conjunto de datos de prueba. Nos referiremos a esta tabla como tabla de criptogramas en el resto de este documento. En caso de que el sistema de ML no quiera revelar el número de muestras en el conjunto de prueba, el auditor y el sistema de ML pueden acordar públicamente n. En este caso, n debe ser lo suficientemente grande como para que los verificadores universales estén satisfechos con el resultado.

Cada fila de la tabla de criptograma resume tres parámetros: (1) estado de membresía del grupo protegido, (2) su etiqueta real y (3) etiqueta prevista por el modelo ML. Cada fila contiene el formato cifrado de los tres parámetros junto con pruebas de su corrección. En la Tabla 3 se muestra una tabla de criptograma en la fase de configuración. En el caso más simple, cada parámetro es binario. Por lo tanto, los parámetros combinados generarán ocho permutaciones en total. En la fase de configuración, se genera la tabla para contener las ocho permutaciones posibles y sus pruebas para cada muestra de datos. La estructura total de las permutaciones se muestra en la Tabla 2. Cada fila satisfará cuatro propiedades: (a) se puede verificar fácilmente si un único criptograma es la versión cifrada de una de las ocho permutaciones posibles, (b) aunque sea verificable, aunque solo sea un solo criptograma seleccionado, no se puede determinar qué permutaciones representa el criptograma actual, (c) por cada dos criptogramas seleccionados de una sola fila, cualquiera podrá distinguirlos entre sí, y (d) dado un conjunto de criptogramas seleccionados arbitrariamente de cada fila como un conjunto, se puede comprobar fácilmente cuántos casos para cada "permutación" hay en el conjunto.

La generación de las funciones de la tabla de criptogramas se basa en la siguiente secuencia:

Paso (1): Para cada una de las n muestras, el sistema genera una clave pública aleatoria g xi donde xi es la clave privada y xi ∈ [1, q − 1].

Paso (3): El número de columna correspondiente que es igual al valor decimal de la codificación binaria se selecciona de la tabla de criptogramas para completar la tabla de auditoría de equidad (como se muestra en la Tabla 2).

Finalmente, la tabla de auditoría de equidad generada es firmada digitalmente por el sistema ML y luego se envía a través del servicio de auditoría de equidad.

3.3.3 Fase III: Evaluación de equidad

En primer lugar, el servicio de auditoría de equidad recibe la tabla de auditoría de equidad, verifica la firma digital y los ZKP y publica el contenido en el panel de equidad.

En este punto, ampliamos cada uno de estos componentes de la ecuación para compararlos entre sí.

Este proceso es computacionalmente pesado, especialmente cuando la cantidad de muestras de datos en la tabla de auditoría de equidad es grande. En este caso, el auditor de equidad puede delegar la declaración del número de permutación al sistema ML. El auditor aún recibe la tabla de auditoría de equidad y los ZKP correspondientes. Puede almacenar la tabla de auditoría de equidad en el tablero de equidad, calcular la equidad y verificar la exactitud de los números de permutación declarados. El verificador universal puede seguir los mismos pasos para verificar los cálculos de las métricas de equidad a través de la tabla de auditoría de equidad a la que se puede acceder públicamente a través del consejo de equidad.

Al final de esta etapa, el auditor utiliza los números adquiridos para calcular la métrica de equidad y publicar la información. El número de cada permutación indica el rendimiento general del algoritmo ML para cada uno de los grupos con atributo protegido. La Tabla 4 demuestra las permutaciones y cómo se relacionan con la métrica de equidad del sistema ML. La tabla de criptogramas y los resultados se publicarán en el tablero de equidad (Fig. 1)