Cómo la ciberseguridad transforma el mercado de TI (Parte 1)

¿Cómo puede cambiar la estructura de toda la esfera de TI si algunos sistemas de protección de derechos de autor, control, autenticación, monitoreo y criptografía nos brindan no solo mejores herramientas, sino también tecnologías fundamentalmente nuevas para trabajar con datos? Esto puede afectar no solo al mercado de TI, sino también al mercado laboral. Tal transformación tecnológica, como cualquier otra, creará una necesidad de nuevo personal y dejará a otros sin trabajo.



imagen



Con esta publicación, planeo comenzar una serie de artículos sobre cómo las nuevas tecnologías en el campo de la ciberseguridad pueden transformar toda la industria de TI. Por lo general, a la lucha contra las amenazas se le asigna una función auxiliar, y pocas personas piensan que en un futuro cercano, las tecnologías de protección pueden cambiar significativamente nuestra vida, haciéndola no solo más segura, sino fundamentalmente diferente. En mis pronósticos, intentaré enfocarme en el período de 5 a 30 años. Si lleva más de 30 años, puede pasar a la abstracción por completo, y si es inferior a 5, el pronóstico será demasiado obvio. En la primera parte, hablaremos de un nuevo mercado para el trabajo intelectual, que está prácticamente ausente en este momento, este es el mercado de algoritmos.



Cada programador que estuvo involucrado en tareas complejas de optimización, desarrolló nuevas funciones criptográficas o recibió un nuevo resultado significativo del desarrollo de ML / AI, surgió la idea: ¿es posible vender algoritmos que hayan ocupado una gran cantidad de trabajo intelectual, y algo? ganar dinero con ellos? Por lo general, la respuesta a esta pregunta es no. A veces puede venderlo, pero solo una vez y solo a algunos servicios especiales con la obligación de no usarlo en ningún otro lugar. Cuando estaba en la escuela de posgrado en el Departamento de Análisis de Sistemas, los estudiantes de posgrado locales escribieron muchos trabajos interesantes y significativos sobre la optimización multicriterio, en los que lograron mejorar los algoritmos individuales y obtener un resultado que era un porcentaje mucho más preciso que el existente. Sin embargo, nunca se siguió la comercialización de estos desarrollos,con la excepción de vender I + D como un servicio.



¿Puedo vender algoritmos?



Analicemos la complejidad de tal operación usando un ejemplo separado. Digamos que un desarrollador ha creado una nueva función hash que es probablemente resistente a colisiones. Un resultado tan útil lo llevó a la idea de que sería bueno vender el acceso a la función hash. Hay dos formas de implementar esto:



1. En la nube: Colóquelo en algún lugar de la nube y proporcione el servicio HASHaaS. Hoy, esta solución es tan simple como no tiene sentido. Incluso si imaginamos que la velocidad y la calidad del canal de comunicación son suficientes para garantizar el SLA requerido de las llamadas a funciones, enfrentaremos la dificultad de enviar los datos a la nube. Es probable que la información que queremos analizar tenga algún valor para nosotros. Por ejemplo, podemos encontrar la función hash de un documento para una certificación adicional con una firma digital electrónica o usar hash de contraseñas de usuario para no almacenarlas en la base de datos. Enviar contraseñas en forma clara a algún servidor extranjero, para obtener un hash más tarde, parece absurdo. Si los encripta para su transmisión, el servidor remoto aún tendrá que desencriptarlos para calcular los hashes. Así,Recibirá todas las contraseñas, todos los documentos y cualquier otro dato que queramos hacer hash. El uso del modelo de nube no es viable, excepto en algunos casos excepcionales en los que la información enviada al servidor remoto no tiene ningún valor para nosotros. Pero tales situaciones serán más bien la excepción a la regla.



2. On-premise. La segunda forma implica transferir el algoritmo directamente al lado del cliente, donde lo ejecutará él mismo. Hay varias dificultades aquí. Si pasamos un programa en un lenguaje interpretado (abierto), como Python, entonces el cliente puede hacer lo que quiera con él. Será imposible controlar más copias y modificaciones del código. Si lo pasamos en forma compilada, entonces, en primer lugar, no siempre es conveniente para el cliente, y en segundo lugar, rastrear la lógica del algoritmo y multiplicarlo no será difícil. Incluso si confundimos el código de antemano y eliminamos toda la información de depuración, podemos desarmar y rastrear la lógica del algoritmo, ya que, muy probablemente, la cantidad de código para el análisis no será demasiado grande. Por lo tanto, ambas trayectorias llevan al programador al fracaso. El pensamiento degenerar propiedad intelectual en forma de algunos algoritmos especializados y vivir de ingresos pasivos de ella toda mi vida sigue siendo un sueño ... ¿O no?



La revolución de los últimos años.



Algunas áreas teóricas de la criptografía en los últimos diez años han recorrido un largo camino desde las construcciones teóricas irrealizables hasta las soluciones aplicadas. Una de estas áreas es el cifrado homomórfico.



El homomorfismo del cifrado es que los cambios en el texto cifrado son similares a los cambios realizados en el texto original. Digamos que Enc () es una función de cifrado, y Dec () es un descifrado; entonces el homomorfismo de adición se puede expresar como x + y = Dec ( Enc ( x ) + Enc ( y )). Del mismo modo, por multiplicación: xy= Dec ( Enc ( x ) ∙ Enc ( y )). Si un cifrado tiene un homomorfismo de suma y multiplicación al mismo tiempo, entonces se llama Cifrado totalmente homomórfico (FHE). ¿Por qué es esto suficiente? Porque cualquier esquema lógico se puede construir sobre estas operaciones. En particular, NAND ( A , B ) = 1 + AB, y NAND, a su vez, es una puerta universal (puerta universal), es decir, a través de ella puede expresar cualquier otro operador lógico y escribir cualquier programa. Las primeras ideas sobre cifrados homomórficos aparecieron hace mucho tiempo, en 1976. Sin embargo, la primera implementación de un cifrado de este tipo solo se describió en 2009 ( Craig Gentry. Cifrado totalmente homomórfico utilizando redes ideales. En el 41º Simposio de ACM sobre Teoría de la Computación (STOC), 2009 ). Este diseño tenía una aplicación práctica tan limitada que requirió aproximadamente 30 minutos de cómputos para una operación elemental con suficiente fuerza criptográfica de la longitud de la clave. En los próximos años, han surgido muchos esquemas de FHE diferentes que son más adecuados para implementaciones prácticas. Algunos de los más famosos son BGV y CKKS (Z. Brakerski, C. Gentry y V. Vaikuntanathan. Cifrado totalmente homomórfico sin Bootstrapping, ITCS 2012 y Cheon, Jung Hee; Kim, Andrey; Kim, Miran; Canción, Yongsoo. Cifrado homomórfico para aritmética de números aproximados. Avances en criptología - ASIACRYPT 2017. Springer, Cham. páginas. 409-437 ). Esto fue seguido por la aparición de muchas implementaciones de código abierto y bibliotecas que implementan cifrados homomórficos. Uno de los primeros fue IBM con su biblioteca HElib (2013), luego HEAAN de la Universidad Nacional de Seúl (2016), PALISADE de DARPA (2017), SEAL extendido de Microsoft (2018) y muchas otras implementaciones, incluidas las aceleradas por GPU, FPGA, etc.



Usando el ejemplo de FHE, uno puede ver cómo en 10 años se ha recorrido el camino desde ideas teóricas abstractas hasta soluciones específicas aplicadas. La criptografía homomórfica abre una serie de nuevas perspectivas: por ejemplo, permite trabajar con datos sin descifrar. Anteriormente, para extraer y procesar información de una gran base de datos cifrada, primero era necesario descargar la base de datos completa, descifrarla, cambiarla en los lugares correctos, y luego cifrarla y enviarla nuevamente. Ahora esto se puede hacer en una sola operación. En una base de datos cifrada, encontramos inmediatamente la celda deseada y la modificamos sin recurrir a descifrar toda la tabla.



Ahora, volviendo al esquema "en la nube", podemos implementar una plataforma de negociación remota ("marketplace") de algoritmos, donde será posible enviar datos no abiertos, sino cifrados. Esto hace que el diseño del negocio sea mucho más realista. Ahora, cualquier acceso al servicio no obliga al cliente a revelar nada. Podemos enviar información personal, grandes datos acumulados y cualquier otra información confidencial encriptada y recibir el resultado del procesamiento en forma encriptada, la clave que solo nosotros tenemos.



Otra trayectoria es vender el acceso al algoritmo en las instalaciones. Aquí vale la pena prestar atención a otro descubrimiento de criptografía en los últimos años. Esta es la llamada ofuscación indistinguible. Por primera vez, la idea de ofuscación indistinguible se expresó en 2001 ( B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, SP Vadhan y K. Yang. Sobre la (im) posibilidad de programas de ofuscación. CRYPTO, 2001, pp. 1-18) en relación con la necesidad de repensar el problema formal de la ofuscación, ya que los enfoques anteriores desde un punto de vista matemático no eran del todo correctos y no daban indicadores mensurables de qué tan bien o mal estaba el programa ofuscado. En 2013, prácticamente el mismo equipo de investigadores propuso una solución al problema que se plantearon en 2001. Se las arreglaron para encontrar un diseño que podría ser un candidato para tal ofuscador ( Sanjam Garg; Craig Gentry; Shai Halevi; Mariana Raykova; Amit Sahai; Brent Waters. Candidato de indistinguibilidad, ofuscación y cifrado funcional para todos los circuitos. Focs 2013, 40-49 ). La esencia de la ofuscación indistinguible se puede explicar de la siguiente manera. Digamos que tenemos un programa obf(), que recibe un cierto código de programa como entrada, y lo emite en forma ofuscada (confusa) en la salida. Además, si tenemos dos programas de igual funcionalidad, A y B , luego de haber recibido sus variantes ofuscadas obf ( A ) y obf ( B), nosotros, con una precisión de valores insignificantes, no podremos entender cuál de los dos fue alimentado a la entrada del ofuscador (se utiliza un enfoque similar para formular la indistinguibilidad de los algoritmos de cifrado). De esto se derivan varias conclusiones no obvias, una de las cuales es la capacidad del programa para almacenar el "secreto" dentro de sí mismo a la salida del ofuscador. Puede ser, por ejemplo, una clave de cifrado; luego se transmite junto con el código ejecutable y, al mismo tiempo, no se puede extraer.



Las posibles bonificaciones por el uso de ofuscación indiscernible no se limitan a esto. Otra consecuencia importante del uso de código indiscernible es que no tiene que confiar en el hardware. Cualquier procesamiento de datos se puede realizar en hardware no confiable. Como resultado, miles de millones gastados en el desarrollo de computadoras domésticas, o la confrontación entre Huawei y los Estados Unidos, no tienen sentido si se argumentan por los requisitos de confianza en el hardware. Pero esto ya es tema de otro artículo.



En el caso de los algoritmos de venta, es posible transferir su código ofuscado al cliente. Al mismo tiempo, incluso si ponemos en el código alguna individualización para un determinado usuario, el cliente no podrá "extraer" esta parte personalizada del código. Como resultado, no solo hacemos que sea imposible analizar los principios del algoritmo, sino que también obtenemos una forma de suministrarles a los programas una determinada etiqueta inseparable, que siempre dejará una marca digital cuando se distribuya en Internet. Sin embargo, vale la pena señalar que la implementación actual de la ofuscación indistinguible es tan engorrosa que es demasiado pronto para hablar de su uso práctico. Lo más probable (a diferencia de en la nube), veremos el esquema de implementación en las instalaciones no antes de 10 años.



Pronósticos y advertencias



Por lo tanto, vemos que en los próximos 5 años o más, el mercado de algoritmos puede aparecer en forma de esquemas en la nube y, posteriormente, es posible realizar "en las instalaciones". Por supuesto, esto no sucederá de la noche a la mañana. Para la formación de tal relación aún debe aparecer:



  1. La plataforma (o plataformas) para el intercambio de datos entre proveedores y consumidores de algoritmos. Deben realizar automáticamente todas las funciones de FHE al nivel de una determinada capa de transporte. Entonces, el servicio será realmente conveniente y, lo más importante, comprensible para todos los participantes del mercado, porque ahora pocos expertos en TI saben qué es FHE y cómo aplicarlo.
  2. El gran intercambio de datos todavía se ve obstaculizado por la velocidad limitada de los canales de comunicación. Por lo tanto, aquí es necesario esperar hasta que el ancho de banda de los canales crezca orgánicamente a los valores requeridos, o lanzar servicios de preprocesamiento de datos adicionales en el lado del cliente, que pueden formar parte de las plataformas y marcos en la sección 1.


El desarrollo del mercado de algoritmos puede tener un impacto significativo en muchos sectores de la economía. Hay varias áreas que definitivamente serán influenciadas por esta transformación.



Big dataLa configuración del mercado moderno de big data consiste no solo en los conjuntos de datos en sí, sino también, y más aún, en centros de análisis que pueden extraer conocimiento y construir modelos basados ​​en esta información. Cada gran recolector de datos, como un operador de telecomunicaciones, banco o minorista, tiene su propio equipo de analistas que desarrollan modelos de extracción de conocimiento y venden estos materiales a otros consumidores. Si un mercado rico de algoritmos y modelos para trabajar con datos está disponible gratuitamente, estas unidades perderán su importancia. Las unidades Bigdat ya no podrán aumentar el valor agregado de la información extraída de Big Data y se verán obligadas a vender solo material "en bruto", cuyo costo también comenzará a devaluarse con el tiempo, comocómo las materias primas clásicas (petróleo, gas, aluminio, etc.) se están depreciando ahora.



Tres niveles de desarrollo. La dicotomía clásica del desarrollo en este momento es el "back-end y frontend". El último escribe la interfaz de usuario, el primero: la lógica completa del servidor de la aplicación. Aquí se puede formar una nueva capa, que se puede designar como "algoend". Se le presentarán los algoritmos clave, más importantes y complejos (PNL, ML / AI, Minería de datos, Blockchain, etc.). En otras palabras, algoend es el contenido esencial de cualquier desarrollo, y frontend y backend son su individualización para un proyecto específico. Algoend requerirá calificaciones máximas y entrará en el campo de los servicios adicionales, formando un nuevo mercado para los servicios. A su vez, el frontend y el backend son un mercado laboral, cuyo costo disminuirá.



Mercado C2B.Ya desde los primeros dos puntos, uno puede sacar una conclusión sobre la transformación que tiene lugar en el mercado laboral. El desarrollo de nuevas tecnologías en el campo de la ciberseguridad permitirá revivir el sector C2B, ahora prácticamente ausente. En otras palabras, estamos pasando de esquemas legales para controlar la propiedad intelectual (por los cuales solo las grandes corporaciones pueden luchar ahora) a esquemas tecnológicos que cualquiera puede usar. Si la propiedad intelectual producida es inseparable del servicio que la utiliza, entonces no hay necesidad de costos legales y organizativos para mantener el régimen de su uso.



Mercado de servicios jurídicos. Es universalmente reconocido que la transición a una economía de la información crea una gran demanda de abogados involucrados en patentes y disputas legales. Hasta cierto momento, realmente lo fue. Sin embargo, 10 o más años antes, predeciría la muerte completa de este mercado de servicios (al menos en el campo de TI). Ya ahora, patentar y registrar algoritmos parece un procedimiento poco práctico y realmente protector, todos los desarrolladores están más inclinados a dejar desarrollos importantes como una especie de conocimiento que divulgar y patentar los resultados. Aquí se agrega otro hecho importante: el código en la salida de un ofuscador indistinguible no puede tener derechos de autor. Esto se desprende de la definición misma de ofuscación indistinguible, ya que es imposible determinar y probarqué tipo de estructura de software se le proporcionó en la entrada. Predeciría que no habrá más disputas legales en la industria de TI 10 años después, al menos, en la forma en que las presentamos ahora.



Las predicciones expresadas en este artículo, por supuesto, como cualquier otra predicción, pueden no hacerse realidad. El descubrimiento y el desarrollo en I + D es el área más ingrata para pronosticar. No podemos decir, por ejemplo, que los diseños complejos actuales de ofuscación indistinguible mejorarán y se volverán prácticos en 5 años. Esto puede no suceder. Sería más correcto suponer que los pronósticos y conclusiones de este artículo se harán realidad con una alta probabilidad, pero los intervalos de tiempo para los que se establecen son significativamente más inciertos.



El artículo original fue publicado aquí.



All Articles