Arquitetura FaaS e justiça verificável para sistemas de ML

Tabela de links

Resumo e introdução

Antecedentes e Trabalhos Relacionados

Arquitetura FaaS

Implementação e Análise de Desempenho

Conclusão

Agradecimentos e Referências

3 Arquitetura FaaS

Nesta seção apresentamos a arquitetura do nosso sistema (Fig. 1) e descrevemos suas características. A arquitetura FaaS inclui partes interessadas em três funções: A) Sistema de ML: um sistema que possui os dados e o algoritmo de ML, B) Serviço de Auditor de Justiça: um serviço que calcula o desempenho justo do sistema de ML, e C) Verificador Universal: qualquer pessoa quem tem conhecimento técnico e motivação para verificar o processo de auditoria.

3.1 Modelo de ameaça

O projeto e a implementação da segurança das partes que implementam as respectivas funções de protocolo (sistema ML, Fairness Auditor Service e Universal Verifier) (Fig. 1) são independentes entre si. As intercomunicações que acontecem entre as funções não pressupõem confiança entre as partes; portanto, todas as suas reivindicações devem ser acompanhadas de provas de validação (para as quais utilizaremos ZKP). Presumimos que o Sistema Auditor é vulnerável a diferentes ataques e não é confiável. Assim, os dados armazenados no Fairness Auditor System devem ser criptografados, invioláveis e verificáveis em todas as etapas. Além disso, assumimos que o canal de comunicação entre o sistema de ML e o auditor de justiça não está protegido. Portanto, os dados confidenciais devem ser criptografados antes do início da transmissão. Contudo, haverá um acordo sobre as primitivas criptográficas na fase de pré-configuração na sequência do protocolo.

No FaaS, assumimos que o sistema ML é honesto no envio dos criptogramas dos rótulos originais das amostras do conjunto de dados. Pode-se argumentar contra tal suposição e discutir que o sistema de ML pode ter a intenção de enganar o Serviço de Auditoria e, por extensão, os verificadores, modificando os rótulos reais do conjunto de dados. Por exemplo, o sistema de ML forneceria os criptogramas dos rótulos reais e dos previstos tão semelhantes quanto possível, para que o auditor concluísse que os algoritmos são justos. Esta é uma área interessante para futuras pesquisas. Por exemplo, pode ser resolvido fornecendo os criptogramas dos rótulos reais ao Serviço de Auditoria de forma independente, por exemplo, o verificador pode possuir um conjunto de dados que fornece a um sistema de ML. O verificador então decide separadamente os valores desejados para os rótulos reais e os alimenta no serviço Auditor. Desta forma, é muito menos claro para o sistema de ML como manipular os dados que envia ao auditor, uma vez que alguns dos rótulos vêm de outro lugar.

A segurança interna das funções vai além do FaaS. O próprio sistema de ML precisa considerar medidas extras para proteger seus dados e algoritmos. Presumimos que o sistema de ML apresenta os dados e as previsões honestamente. Esta é uma suposição razoável, uma vez que os incentivos para um desempenho ético contrastam com ser desonesto ao participar no processo de auditoria de justiça. Isso é discutido mais na seção de discussão.

Tabela 2: Possíveis permutações de representação de 3 bits de uma entrada nos dados originais.

3.2 Visão Geral do Protocolo

A principal sequência do protocolo de segurança é entre o sistema ML e o Fairness Auditing Service ou auditor resumido. Observe que embora sugerimos três funções em nossa arquitetura, as comunicações são principalmente entre as duas funções acima, e qualquer verificador universal pode recorrer ao serviço de auditor (que representa o conselho de justiça), se quiser desafiar os cálculos.

O sistema ML é responsável pela implementação e execução do algoritmo ML. Ele tem dados como entrada e realiza algumas previsões (dependendo do caso de uso e da finalidade) que formam a saída (Fig. 1). O Fairness Auditor Service recebe informações do sistema ML e avalia seu desempenho de imparcialidade calculando uma métrica de imparcialidade. Em seguida, ele retorna o resultado da métrica ao sistema de ML. Também publica os cálculos num quadro de imparcialidade para verificação pública. O painel de justiça público é um quadro de justiça acessível ao público e somente leitura (por exemplo, um website). O auditor só tem o direito de anexar dados (e provas suficientes) ao conselho de justiça. Além disso, o auditor verifica a autenticidade, exatidão e integridade dos dados antes de publicá-los.

3.3 Sequência do Protocolo

Este protocolo possui três estágios: configuração, geração de criptograma e cálculo de métricas de justiça.

3.3.1 Fase I: Configuração

Nesta fase, o Sistema ML e o Auditor concordam com as configurações iniciais. Assumimos que o protocolo funciona na configuração de grupo cíclico multiplicativo (ou seja, grupo semelhante ao Algoritmo de Assinatura Digital (DSA) [18]), mas também pode funcionar em grupos cíclicos aditivos (ou seja, grupos semelhantes ao Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) [18 ]). O auditor e o sistema ML concordam publicamente com (p, q, g) antes do início do protocolo. Sejam p e q dois números primos grandes onde q|(p − 1). Em um grupo cíclico multiplicativo (Z ∗ p ), Gq é um subgrupo de ordem prima q eg é seu gerador. Para simplificar, assumimos que o problema da Decisão Diffie-Hellman (DDH) está fora do escopo [31].

Em seguida, o sistema ML gera uma chave de par pública/privada usando DSA ou ECDSA e publica as chaves públicas no fairness board. A proteção do par de chaves privadas depende da arquitetura de segurança do sistema ML e assumimos que a chave privada é armazenada de forma segura em uma prática padrão industrial (por exemplo, usando o módulo de memória seguro integrado).

Tabela de criptograma: Após acordos iniciais, o sistema ML produz uma tabela de criptograma com n linhas correspondentes ao número de amostras em seu conjunto de dados de teste. Iremos nos referir a esta tabela como tabela de criptograma no restante deste artigo. Caso o sistema ML não queira revelar o número de amostras no conjunto de teste, o auditor e o sistema ML podem concordar publicamente sobre n. Neste caso, n deve ser grande o suficiente para que os verificadores universais fiquem satisfeitos com o resultado.

Cada linha na tabela de criptograma resume três parâmetros: (1) status de membro do grupo protegido, (2) seu rótulo real e (3) rótulo previsto pelo modelo de ML. Cada linha contém o formato criptografado dos três parâmetros junto com provas de sua correção. Uma tabela de criptograma na fase de configuração é mostrada na Tabela 3. No caso mais simples, cada parâmetro é binário. Portanto, os parâmetros combinados gerarão oito permutações no total. Na fase de configuração, a tabela é gerada para conter todas as oito permutações possíveis e suas provas para cada amostra de dados. A estrutura total das permutações é mostrada na Tabela 2. Cada linha irá satisfazer quatro propriedades: (a) pode-se facilmente verificar se um único criptograma é a versão criptografada de uma das oito permutações possíveis, (b) embora verificável, se apenas um único criptograma selecionado, não se pode determinar quais permutações o criptograma atual representa, (c) para cada dois criptogramas selecionados de uma única linha, qualquer um será capaz de distinguir um do outro, e (d) dado um conjunto de criptogramas selecionados arbitrariamente de cada linha como um conjunto, pode-se facilmente verificar quantos casos para cada “permutação” existem no conjunto.

A geração das funções da tabela do criptograma é baseada na seguinte sequência:

Passo (1): Para cada uma das n amostras, o sistema gera uma chave pública aleatória g xi onde xi é a chave privada e xi ∈ [1, q − 1].

Etapa (3): O número da coluna correspondente que é igual ao valor decimal da codificação binária é selecionado na tabela de criptograma para completar a tabela de auditoria de justiça (conforme mostrado na Tabela 2).

Por fim, a tabela de auditoria de imparcialidade gerada é assinada digitalmente pelo sistema ML e depois enviada pelo serviço de auditoria de imparcialidade.

3.3.3 Fase III: Avaliação de Justiça

Primeiro, o serviço de auditoria de justiça recebe a tabela de auditoria de justiça, verifica a assinatura digital e os ZKPs e publica o conteúdo no quadro de justiça.

Neste ponto, expandimos cada um desses componentes da equação para compará-los.

Este processo é computacionalmente pesado, especialmente quando o número de amostras de dados na tabela de auditoria de justiça é grande. Neste caso, o auditor de imparcialidade pode delegar a declaração do número de permutação ao sistema ML. O auditor ainda recebe a tabela de auditoria de imparcialidade e os ZKPs relevantes. Ele pode armazenar a tabela de auditoria de imparcialidade no quadro de imparcialidade, calcular a imparcialidade e verificar a exatidão dos números de permutação declarados. O verificador universal pode seguir as mesmas etapas para verificar os cálculos da métrica de imparcialidade por meio da tabela de auditoria de imparcialidade que é acessível publicamente por meio do quadro de imparcialidade.

Ao final desta etapa, o auditor utiliza os números adquiridos para calcular a métrica de justiça e divulgar as informações publicamente. O número de cada permutação denota o desempenho geral do algoritmo de ML para cada um dos grupos com atributo protegido. A Tabela 4 demonstra as permutações e como elas se relacionam com a métrica de justiça do sistema ML. A tabela de criptograma e os resultados serão publicados no fairness board (Fig. 1)