Com esta publicação, pretendo iniciar uma série de artigos sobre como as novas tecnologias no campo da segurança cibernética podem transformar todo o setor de TI. Geralmente, a luta contra ameaças recebe uma função auxiliar, e poucas pessoas pensam que, em um futuro próximo, as tecnologias de proteção podem mudar significativamente nossa vida, tornando-a não apenas mais segura, mas fundamentalmente diferente. Nas minhas previsões, tentarei focar no período de 5 a 30 anos. Se você demorar mais de 30 anos, poderá abstrair completamente e, se for menor que 5, a previsão será muito óbvia. Na primeira parte, falaremos sobre um novo mercado de trabalho intelectual, praticamente ausente no momento, este é o mercado de algoritmos.
Todo programador que lidou com problemas complexos de otimização, desenvolveu novas funções criptográficas ou recebeu algum novo resultado significativo no desenvolvimento de ML / AI, surgiu o pensamento: é possível vender algoritmos para os quais uma quantidade tão grande de trabalho intelectual foi gasta e algo ganhar dinheiro com eles? Por via de regra, a resposta a esta pergunta é não. Às vezes você pode vender, mas apenas uma vez e apenas para alguns serviços especiais com a obrigação de não usá-lo em nenhum outro lugar. Quando eu estava na faculdade no Departamento de Análise de Sistemas, os estudantes locais escreveram muitos trabalhos interessantes e significativos sobre otimização multicritério, nos quais eles conseguiram melhorar algoritmos individuais e obter um resultado vários por cento mais preciso do que o existente. No entanto, o desenvolvimento posterior desses desenvolvimentos nunca foi seguido.com a exceção de vender a P&D em si como um serviço.
Algoritmos podem ser vendidos?
Vamos analisar a complexidade de uma operação desse tipo usando um exemplo separado. Digamos que um desenvolvedor tenha criado uma nova função de hash comprovadamente resistente a colisões. Um resultado tão útil o levou a pensar que seria bom vender o acesso à função hash. Há duas maneiras de fazer isso:
1. Na nuvem: hospedar em algum lugar da nuvem e fornecer o serviço HASHaaS. Hoje, essa decisão é tão simples quanto sem sentido. Mesmo se imaginarmos que a velocidade e a qualidade do canal de comunicação são suficientes para garantir o SLA exigido das chamadas de função, enfrentaremos a dificuldade de enviar os dados para a nuvem. As informações que queremos incluir no hash provavelmente terão algum valor para nós. Por exemplo, podemos encontrar a função de hash de um documento para obter mais certificação com uma assinatura digital eletrônica ou usar hash de senhas de usuário para não armazená-las no banco de dados. Parece absurdo enviar senhas em texto não criptografado para algum servidor estrangeiro para obter um hash mais tarde. Se você os criptografar para transmissão, o servidor remoto ainda precisará descriptografar para calcular os hashes. Portanto,ele receberá todas as senhas, todos os documentos e outros dados que desejamos fazer hash. O uso do modelo de nuvem acaba sendo inviável, exceto em alguns casos raros, quando as informações enviadas para um servidor remoto não têm absolutamente nenhum valor para nós. Mas tais situações são mais provavelmente uma exceção à regra.
2. On-premise. A segunda maneira envolve a transferência do algoritmo diretamente para o lado do cliente, onde ele será executado. Existem várias dificuldades aqui. Se passarmos um programa em uma linguagem interpretada (aberta), como Python, o cliente poderá fazer o que quiser com ele. Será impossível controlar cópias e modificações adicionais do código. Se o transferirmos na forma compilada, em primeiro lugar, nem sempre é conveniente para o cliente e, em segundo lugar, não será difícil rastrear a lógica do algoritmo e replicá-la. Mesmo se confundirmos o código antecipadamente e removermos todas as informações de depuração, podemos desmontar e rastrear a lógica do algoritmo, pois, provavelmente, a quantidade de código para análise não será muito grande. Assim, ambas as trajetórias levam o programador ao fracasso. O pensamento degerar propriedade intelectual na forma de algoritmos especializados e viver disso com renda passiva a vida toda - continua sendo um sonho ... Ou não?
A revolução dos últimos anos
Algumas áreas teóricas da criptografia nos últimos dez anos percorreram um longo caminho, desde construções teóricas irrealizáveis até soluções aplicadas. Uma dessas áreas é a criptografia homomórfica.
O homomorfismo da cifra é que as alterações no texto cifrado são semelhantes às alterações feitas no texto original. Digamos que Enc () é uma função de criptografia e Dec () é uma descriptografia; então o homomorfismo de adição pode ser expresso como x + y = Dec ( Enc ( x ) + Enc ( y )). Da mesma forma - por multiplicação: x ∙ y= Dec ( Enc ( x ) ∙ Enc ( y )). Se uma cifra possui um homomorfismo, além de multiplicação, é chamada de Criptografia Totalmente Homomórfica (FHE). Por que isso é suficiente? Porque nessas operações, você pode construir qualquer circuito lógico. Em particular, NAND ( A , B ) = 1 + A ∙ B, e NAND, por sua vez, é um portão universal, ou seja, através dele você pode expressar qualquer outro operador lógico e escrever qualquer programa. As primeiras idéias sobre cifras homomórficas surgiram há muito tempo - em 1976. No entanto, a primeira implementação dessa cifra foi descrita apenas em 2009 ( Craig Gentry. Criptografia totalmente homomórfica usando redes ideais. No 41º Simpósio ACM de Teoria da Computação (STOC), 2009 ). Esse projeto era tão limitado em aplicações práticas que exigia cerca de 30 minutos de cálculos para uma operação elementar com força criptográfica suficiente do comprimento da chave. Ao longo dos próximos anos, surgiram muitos esquemas de ESF mais adequados para implementações práticas. Alguns dos mais famosos são BGV e CKKS (Z. Brakerski, C. Gentry e V. Vaikuntanathan. Criptografia totalmente homomórfica sem inicialização, ITCS 2012 e Cheon, Jung Hee; Kim, Andrey; Kim, Miran; Canção, Yongsoo. Criptografia homomórfica para aritmética de números aproximados. Avanços em Criptologia - ASIACRYPT 2017. Springer, Cham. pp. 409-437 ). Isso foi seguido pelo surgimento de muitas implementações e bibliotecas de código aberto que implementam cifras homomórficas. Um dos primeiros foi a IBM, com sua biblioteca HElib (2013), depois o HEAAN, da Universidade Nacional de Seul (2016), o PALISADE , da DARPA (2017), o SEAL estendido da Microsoft (2018) e muitas outras implementações, inclusive aceleradas por GPU, FPGA, etc.
O exemplo da FHE mostra como, em 10 anos, o caminho passou de idéias teóricas abstratas para soluções concretas aplicadas. A criptografia homomórfica abre várias novas perspectivas: por exemplo, torna possível trabalhar com dados sem descriptografia. Anteriormente, para extrair e processar informações de um grande banco de dados criptografado, era necessário primeiro baixar o banco de dados inteiro, descriptografá-lo, alterá-lo nos lugares certos e, em seguida, criptografar e enviá-lo novamente. Agora isso pode ser feito em uma operação. Em um banco de dados criptografado, localizamos imediatamente a célula desejada e a alteramos sem recorrer à descriptografia da tabela inteira.
Agora, voltando ao esquema na nuvem, podemos implementar uma plataforma de negociação remota ("mercado") de algoritmos onde os dados criptografados podem ser enviados e não abertos. Isso torna o layout da empresa muito mais realista. Agora, qualquer acesso ao serviço não obriga a divulgar nada. Podemos enviar informações pessoais, big data acumulados e quaisquer outras informações confidenciais criptografadas e receber o resultado do processamento também em forma criptografada, cuja chave está apenas conosco.
Outra trajetória é vender o acesso ao algoritmo no local. Aqui vale a pena prestar atenção a outra descoberta de criptografia nos últimos anos. Esta é a chamada ofuscação da indistinguibilidade. A idéia de ofuscação indistinguível foi exposta pela primeira vez em 2001 ( B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, SP Saad, SP Vadhan e K. Yang. Sobre a (im) possibilidade de programas ofuscantes. 2001, pp. 1-18) em conexão com a necessidade de repensar o problema de ofuscação formalizada, uma vez que as abordagens anteriores do ponto de vista matemático não estavam totalmente corretas e não forneceram indicadores mensuráveis de quão bem ou mal o programa foi ofuscado. Em 2013, praticamente a mesma equipe de pesquisadores propôs uma solução para o problema que eles mesmos estabeleceram em 2001. Eles conseguiram encontrar um projeto que pudesse ser candidato ao papel de um ofuscador ( Sanjam Garg; Craig Gentry; Shai Halevi; Mariana Raykova; Amit Sahai; Brent Waters. Ocultação de Indistinguibilidade e Criptografia Funcional de Candidatos para todos os circuitos. Focs 2013, 40-49 ). A essência da ofuscação indistinguível pode ser explicada da seguinte maneira. Digamos que temos um programa obf(), que recebe um determinado código de programa como entrada e o gera de forma ofuscada (confusa) na saída. Além disso, se tivermos dois programas de igual funcionalidade A e B , teremos recebido suas variantes ofuscadas obf ( A ) e obf ( B), com precisão de valores desprezíveis, não conseguiremos entender qual dos dois foi alimentado na entrada do ofuscador (uma abordagem semelhante é usada para formular a indistinguibilidade dos algoritmos de criptografia). A partir disso, seguem-se várias conclusões não óbvias, uma das quais é a capacidade do programa na saída do ofuscador de manter um "segredo" dentro de si. Pode ser, por exemplo, uma chave de criptografia - depois é transmitida junto com o código executável e, ao mesmo tempo, não pode ser extraída.
Os possíveis bônus do uso de ofuscação indiscernível não se limitam a isso. Outra consequência importante do uso de código indiscernível é que você não precisa confiar no hardware. Qualquer processamento de dados pode ser realizado em hardware não confiável. Como resultado, bilhões de dólares gastos no desenvolvimento de computadores domésticos, ou no confronto entre a Huawei e os Estados Unidos, ficam sem sentido se discutidos pelos requisitos de confiança no hardware. Mas esse já é o assunto de outro artigo.
No caso de venda de algoritmos, torna-se possível transferir o código ofuscado para o cliente. Ao mesmo tempo, mesmo se colocarmos no código alguma individualização para um determinado usuário, o cliente não poderá "extrair" essa parte personalizada do código. Como resultado, não apenas impossibilitamos analisar os princípios do algoritmo, como também fornecemos uma maneira de fornecer ao programa uma determinada etiqueta inseparável, que sempre deixará uma marca digital quando distribuída na Internet. No entanto, vale a pena notar que a implementação atual de ofuscação indistinguível é tão complicada que é muito cedo para falar sobre seu uso prático. Muito provavelmente (ao contrário da nuvem), veremos o esquema de implementação no local não antes de 10 anos depois.
Previsões e advertências
Assim, vemos que nos próximos 5 anos ou mais, o mercado de algoritmos poderá aparecer na forma de esquemas de nuvem e, posteriormente, é possível executar no local. Obviamente, isso não acontecerá da noite para o dia. Para formar esses relacionamentos, ainda deve aparecer:
- A plataforma (ou plataformas) para a troca de dados entre provedores e consumidores de algoritmos. Eles devem executar automaticamente todas as funções do FHE no nível de uma camada de transporte. Então, o serviço se tornará realmente conveniente e, o mais importante, compreensível para todos os participantes do mercado, porque agora poucos especialistas em TI sabem o que é FHE e como usá-lo.
- A troca de big data ainda é dificultada pela velocidade limitada dos canais de comunicação. Portanto, aqui é necessário aguardar até que a largura de banda dos canais cresça organicamente até os valores exigidos ou iniciar serviços adicionais de pré-processamento de dados no lado do cliente, que podem fazer parte das plataformas e estruturas na seção 1.
O desenvolvimento do mercado de algoritmos pode ter um impacto significativo em muitos setores da economia. Existem várias áreas que definitivamente serão influenciadas por essa transformação.
Big data.A configuração do mercado moderno de big data é composta não apenas pelos próprios conjuntos de dados, mas também - ainda mais - pelos centros de análise capazes de extrair conhecimento e construir modelos com base nessas informações. Todo coletor de big data, como uma operadora de telecomunicações, banco ou varejo, tem sua própria equipe de analistas que desenvolvem modelos para extrair conhecimento e vendem esses materiais para outros consumidores. Com a disponibilidade de um mercado rico de algoritmos e modelos para trabalhar com dados, essas divisões perderão sua importância. As unidades Bigdat não poderão mais aumentar o valor agregado das informações extraídas do big data e serão forçadas a vender apenas matéria-prima "cujo custo também começará a desvalorizar com o tempo, comocomo as matérias-primas clássicas (petróleo, gás, alumínio etc.) estão se depreciando agora.
Três níveis de desenvolvimento. Atualmente, a dicotomia clássica de desenvolvimento é "back-end versus front-end". O último grava a interface do usuário, o primeiro grava toda a lógica do servidor do aplicativo. Aqui, uma nova camada pode ser formada, que pode ser designada como "algoend". Ele conterá os principais algoritmos mais importantes e complexos (PNL, ML / AI, mineração de dados, blockchain, etc.). Em outras palavras, algoend é o conteúdo essencial de qualquer desenvolvimento, e frontend e backend são sua individualização para um projeto específico. Algoend exigirá qualificações máximas e entrará no campo de serviços adicionais, formando um novo mercado para serviços. Por sua vez, front-end e back-end são o mercado de trabalho, cujo custo diminuirá.
Mercado C2B.Já a partir dos dois primeiros pontos, pode-se chegar a uma conclusão sobre a transformação que está ocorrendo no mercado de trabalho. O desenvolvimento de novas tecnologias no campo da segurança cibernética reviverá o setor C2B, atualmente ausente. Em outras palavras, estamos passando de esquemas legais de controle de propriedade intelectual (que apenas grandes empresas podem combater por enquanto) para esquemas tecnológicos que qualquer pessoa pode usar. Se a propriedade intelectual produzida for inseparável do serviço que a utiliza, não haverá necessidade de custos legais e organizacionais para manter o modo de uso.
Mercado de serviços jurídicos. É geralmente aceito que a transição para a economia da informação cria uma grande demanda por advogados que lidam com patentes e disputas legais. Até um certo momento, era realmente assim. No entanto, com 10 anos ou mais de antecedência, eu previa a morte completa desse mercado de serviços (pelo menos no campo de TI). Agora, patentear e registrar algoritmos parece um procedimento pouco prático e realmente algo de proteção, todos os desenvolvedores estão mais inclinados a deixar desenvolvimentos importantes como uma espécie de know-how, em vez de divulgar e patentear os resultados. Outro fato importante é adicionado aqui - o código na saída de um ofuscador indistinguível não pode ser objeto de direitos autorais. Isso decorre da própria definição de ofuscação indistinguível, uma vez que é impossível determinar e provarque tipo de estrutura de software lhe foi fornecida na entrada. Eu preveria que não haverá mais disputas legais no setor de TI dez anos depois, pelo menos - na forma em que a apresentamos agora.
As previsões expressas neste artigo, é claro, como qualquer outra previsão, podem não se tornar realidade. A descoberta e o desenvolvimento em P&D são a área mais ingrata para a previsão. Não podemos dizer, por exemplo, que os projetos complexos atuais de ofuscação indistinguível serão aprimorados e se tornarão práticos em 5 anos. Isso pode não acontecer. Seria mais correto supor que as previsões em si e as conclusões deste artigo provavelmente se tornarão realidade, mas os períodos em que são estabelecidas apresentam uma incerteza significativamente maior.
O artigo original é publicado aqui.