“
Apple Intelligence es el sistema de inteligencia personal que lleva potentes modelos generativos a iPhone, iPad y Mac. Para funciones avanzadas que necesitan razonar sobre datos complejos con modelos de base más grandes, creamos Private Cloud Compute (PCC), un revolucionario sistema de inteligencia en la nube diseñado específicamente para el procesamiento de IA privada. Por primera vez, Private Cloud Compute extiende la seguridad y privacidad líder en la industria de los dispositivos Apple a la nube, asegurando que los datos personales del usuario enviados a PCC no sean accesibles para nadie más que el usuario, ni siquiera para Apple. Construido con silicio personalizado de Apple y un sistema operativo endurecido diseñado para la privacidad, creemos que PCC es la arquitectura de seguridad más avanzada jamás implementada para el procesamiento de IA en la nube a gran escala.
Apple siempre ha defendido el procesamiento en dispositivos como la piedra angular de la seguridad y privacidad de los datos del usuario. Los datos que existen solo en los dispositivos del usuario, por definición están desagregados y no están sujetos a ningún punto centralizado de ataque. Cuando Apple es responsable de los datos del usuario en la nube, los protegemos con seguridad de última generación en nuestros servicios, y para los datos más sensibles, creemos que el cifrado de extremo a extremo es nuestra defensa más poderosa. Para los servicios en la nube donde el cifrado de extremo a extremo no es apropiado, nos esforzamos por procesar datos de usuario de forma efímera o bajo identificadores aleatorios no correlacionados que ocultan la identidad del usuario.
El procesamiento de IA seguro y privado en la nube plantea un formidable desafío nuevo. El hardware de IA potente en el centro de datos puede cumplir una solicitud del usuario con modelos de aprendizaje automático grandes y complejos, pero requiere acceso no cifrado a la solicitud del usuario y los datos personales que la acompañan. Eso excluye el uso del cifrado de extremo a extremo, por lo que las aplicaciones de IA en la nube hasta la fecha han empleado enfoques tradicionales para la seguridad en la nube. Tales enfoques presentan algunos desafíos clave:
Las garantías de seguridad y privacidad en la nube de IA son difíciles de verificar y hacer cumplir. Si un servicio de IA en la nube afirma que no registra ciertos datos de usuario, generalmente no hay forma para que los investigadores de seguridad verifiquen esta promesa, y a menudo no hay forma de que el proveedor del servicio la haga cumplir de manera duradera. Por ejemplo, una nueva versión del servicio de IA puede introducir registros rutinarios adicionales que inadvertidamente registran datos de usuario sensibles sin que un investigador pueda detectarlo. Del mismo modo, un balanceador de carga perimetral que termina TLS puede terminar registrando miles de solicitudes de usuario por completo durante una sesión de resolución de problemas.
Es difícil proporcionar transparencia en tiempo de ejecución para la IA en la nube. Los servicios de IA en la nube son opacos: los proveedores generalmente no especifican detalles de la pila de software que están utilizando para ejecutar sus servicios, y esos detalles a menudo se consideran propietarios. Incluso si un servicio de IA en la nube se basara solo en software de código abierto, que puede ser inspeccionado por investigadores de seguridad, no hay una forma ampliamente desplegada para que un dispositivo de usuario (o navegador) confirme que el servicio al que se está conectando está ejecutando una versión no modificada del software que pretende ejecutar, o para detectar que el software que se ejecuta en el servicio ha cambiado.
Es un desafío para los entornos de IA en la nube hacer cumplir límites estrictos al acceso privilegiado. Los servicios de IA en la nube son complejos y costosos de ejecutar a gran escala, y su rendimiento en tiempo de ejecución y otras métricas operativas son monitoreadas e investigadas constantemente por ingenieros de confiabilidad del sitio y otro personal administrativo en el proveedor de servicios en la nube. Durante interrupciones y otros incidentes graves, estos administradores generalmente pueden hacer uso de un acceso altamente privilegiado al servicio, como a través de SSH e interfaces de shell remotas equivalentes. Aunque los controles de acceso para estas interfaces privilegiadas, como el acceso “break-glass”, pueden estar bien diseñados, es excepcionalmente difícil imponer límites ejecutables en ellos mientras están en uso activo. Por ejemplo, un administrador de servicios que intenta hacer una copia de seguridad de datos de un servidor en vivo durante una interrupción podría copiar involuntariamente datos de usuario sensibles en el proceso. Más perniciosamente, los criminales como los operadores de ransomware trabajan rutinariamente para comprometer las credenciales de los administradores de servicios precisamente para aprovechar las interfaces de acceso privilegiado y llevarse datos de usuario.
Cuando la computación en dispositivos con dispositivos Apple como iPhone y Mac es posible, las ventajas de seguridad y privacidad son claras: los usuarios controlan sus propios dispositivos, los investigadores pueden inspeccionar tanto el hardware como el software, la transparencia en tiempo de ejecución está garantizada criptográficamente a través de Secure Boot, y Apple no conserva ningún acceso privilegiado (como ejemplo concreto, el sistema de cifrado de archivos Data Protection criptográficamente impide que Apple desactive o adivine el código de acceso de un iPhone dado).
Sin embargo, para procesar solicitudes más sofisticadas, Apple Intelligence necesita poder solicitar ayuda de modelos más grandes y complejos en la nube. Para que estas solicitudes en la nube cumplan con las garantías de seguridad y privacidad que nuestros usuarios esperan de nuestros dispositivos, el modelo de seguridad de servicios en la nube tradicional no es un punto de partida viable. En cambio, necesitamos llevar nuestro modelo de seguridad líder en la industria de dispositivos, por primera vez, a la nube.
El resto de esta publicación es una descripción técnica inicial de Private Cloud Compute, que se seguirá con un análisis detallado una vez que PCC esté disponible en beta. Sabemos que los investigadores tendrán muchas preguntas detalladas, y esperamos responder más de ellas en nuestra publicación de seguimiento.
Diseño de Private Cloud Compute
Nos propusimos construir Private Cloud Compute con un conjunto de requisitos fundamentales:
Cómputo sin estado sobre datos personales del usuario. Private Cloud Compute debe utilizar los datos personales del usuario que recibe exclusivamente con el propósito de cumplir la solicitud del usuario. Estos datos nunca deben estar disponibles para nadie que no sea el usuario, ni siquiera para el personal de Apple, ni siquiera durante el procesamiento activo. Y estos datos no deben ser retenidos, incluido a través de registros o para depuración, después de que se devuelva la respuesta al usuario. En otras palabras, queremos una forma sólida de procesamiento de datos sin estado donde los datos personales no dejen rastro en el sistema PCC.
Garantías exigibles. Las garantías de seguridad y privacidad son más sólidas cuando son completamente técnicamente exigibles, lo que significa que debe ser posible limitar y analizar todos los componentes que contribuyen críticamente a las garantías del sistema Private Cloud Compute en su conjunto. Para usar nuestro ejemplo anterior, es muy difícil razonar sobre lo que un balanceador de carga que termina TLS puede hacer con los datos del usuario durante una sesión de depuración. Por lo tanto, PCC no debe depender de componentes externos como esos para sus garantías principales de seguridad y privacidad. Del mismo modo, los requisitos operativos como la recopilación de métricas de servidor y registros de errores deben admitirse con mecanismos que no socaven las protecciones de privacidad.
Sin acceso privilegiado en tiempo de ejecución. Private Cloud Compute no debe contener interfaces privilegiadas que permitan al personal de confiabilidad del sitio de Apple evadir las garantías de privacidad de PCC, incluso cuando trabajan para resolver una interrupción u otro incidente grave. Esto también significa que PCC no debe admitir un mecanismo mediante el cual el sobre de acceso privilegiado pueda ampliarse en tiempo de ejecución, como mediante la carga de software adicional.
No orientabilidad. Un atacante no debería poder intentar comprometer los datos personales de un usuario específico de Private Cloud Compute sin intentar un compromiso amplio de todo el sistema de PCC. Esto debe ser cierto incluso para atacantes excepcionalmente sofisticados que pueden intentar ataques físicos en los nodos de PCC en la cadena de suministro o intentar obtener acceso malicioso a los centros de datos de PCC. En otras palabras, un compromiso limitado de PCC no debe permitir al atacante dirigir solicitudes de usuarios específicos a nodos comprometidos; apuntar a los usuarios debería requerir un ataque amplio que probablemente se detectará. Para comprender esto de manera más intuitiva, contrástalo con un diseño de servicio en la nube tradicional donde cada servidor de aplicación se provisiona con credenciales de base de datos para la base de datos de la aplicación completa, por lo que un compromiso de un solo servidor de aplicación es suficiente para acceder a los datos de cualquier usuario, incluso si ese usuario no tiene sesiones activas con el servidor de aplicación comprometido.
Transparencia verificable. Los investigadores de seguridad deben poder verificar, con un alto grado de confianza, que nuestras garantías de seguridad y privacidad para Private Cloud Compute coinciden con nuestras promesas públicas. Ya tenemos un requisito anterior para que nuestras garantías sean exigibles. Hipotéticamente, entonces, si los investigadores de seguridad tuvieran acceso suficiente al sistema, podrían verificar las garantías. Pero este último requisito, transparencia verificable, va un paso más allá y elimina lo hipotético: los investigadores de seguridad deben poder verificar las garantías de seguridad y privacidad de Private Cloud Compute, y deben poder verificar que el software que se está ejecutando en el entorno de producción de PCC es el mismo que el software que inspeccionaron al verificar las garantías.
Este es un conjunto extraordinario de requisitos, y uno que creemos representa un salto generacional sobre cualquier modelo de seguridad en la nube tradicional.
Introducción de nodos de Private Cloud Compute
La raíz de confianza para Private Cloud Compute es nuestro nodo de cómputo: hardware de servidor personalizado que lleva la potencia y seguridad del silicio de Apple al centro de datos, con las mismas tecnologías de seguridad de hardware utilizadas en iPhone, incluido el Secure Enclave y el Secure Boot. Combinamos este hardware con un nuevo sistema operativo: un subconjunto endurecido de los cimientos de iOS y macOS adaptados para admitir cargas de trabajo de inferencia de modelos de lenguaje grande (LLM) mientras presenta una superficie de ataque extremadamente estrecha. Esto nos permite aprovechar las tecnologías de seguridad de iOS como la Firma de Código y el aislamiento.
Sobre esta base, construimos un conjunto personalizado de extensiones en la nube con la privacidad en mente. Excluimos componentes que son críticos tradicionalmente para la administración del centro de datos, como las conchas remotas e introspección del sistema y herramientas de observabilidad. Reemplazamos esos componentes de software de propósito general con componentes diseñados específicamente para proporcionar de manera determinista solo un conjunto reducido y restringido de métricas operativas al personal de SRE. Y finalmente, usamos Swift en Server para construir una nueva pila de aprendizaje automático específicamente para alojar nuestro modelo de base de la nube.
Volvamos a nuestros requisitos fundamentales de Private Cloud Compute y las características que construimos para lograrlos.
Cómputo sin estado y garantías exigibles
Con servicios que están cifrados de extremo a extremo, como iMessage, el operador del servicio no puede acceder a los datos que atraviesan el sistema. Una de las razones clave por las que estos diseños pueden asegurar la privacidad es específicamente porque impiden que el servicio realice cálculos en los datos del usuario. Dado que Private Cloud Compute necesita poder acceder a los datos en la solicitud del usuario para permitir que un modelo de base grande lo cumpla, el cifrado de extremo a extremo completo no es una opción. En cambio, el nodo de cómputo de PCC debe tener la aplicación técnica de la privacidad de los datos del usuario durante el procesamiento y debe ser incapaz de retener datos del usuario después de que su ciclo de deber esté completo.
Diseñamos Private Cloud Compute para hacer varias garantías sobre la forma en que maneja los datos del usuario:
El dispositivo de un usuario envía datos a PCC con el único y exclusivo propósito de cumplir la solicitud de inferencia del usuario. PCC utiliza esos datos solo para realizar las operaciones solicitadas por el usuario.
Los datos de usuario permanecen en los nodos de PCC que están procesando la solicitud solo hasta que se devuelva la respuesta. PCC elimina los datos del usuario después de cumplir la solicitud, y no se retiene ningún dato del usuario en ninguna forma después de que se devuelva la respuesta.
Los datos del usuario nunca están disponibles para Apple, ni siquiera para el personal con acceso administrativo al servicio o al hardware de producción de PCC.
Cuando Apple Intelligence necesita recurrir a Private Cloud Compute, construye una solicitud, que consiste en el indicador, más el modelo deseado y los parámetros de inferencia, que servirá como entrada al modelo en la nube. El cliente de PCC en el dispositivo del usuario cifra esta solicitud directamente a las claves públicas de los nodos de PCC que primero ha confirmado que son válidos y certificados criptográficamente. Esto proporciona un cifrado de extremo a extremo desde el dispositivo del usuario a los nodos de PCC validados, asegurando que la solicitud no pueda ser accedida en tránsito por nada fuera de esos nodos de PCC altamente protegidos. Los servicios de centro de datos de apoyo, como los balanceadores de carga y los pasarelas de privacidad, se ejecutan fuera de este límite de confianza y no tienen las claves necesarias para descifrar la solicitud del usuario, contribuyendo así a nuestras garantías exigibles.
A continuación, debemos proteger la integridad del nodo de PCC y evitar cualquier manipulación con las claves utilizadas por PCC para descifrar las solicitudes de usuario. El sistema utiliza Secure Boot y Code Signing para garantizar que solo el código autorizado y medido criptográficamente sea ejecutable en el nodo. Todo el código que puede ejecutarse en el nodo debe formar parte de una memoria caché de confianza que haya sido firmada por Apple, aprobada para ese nodo de PCC específico, y cargada por el Secure Enclave de tal manera que no se pueda cambiar o modificar en tiempo de ejecución. Esto también asegura que no se puedan crear mapeos JIT, evitando la compilación o la inyección de nuevos códigos en tiempo de ejecución. Además, todo el código y los activos del modelo utilizan la misma protección de integridad que impulsa el Volumen del Sistema Firmado. Finalmente, el Secure Enclave proporciona una garantía exigible de que las claves que se utilizan para descifrar las solicitudes no pueden duplicarse ni extraerse.
La pila de software de Private Cloud Compute está diseñada para garantizar que los datos del usuario no se filtren fuera del límite de confianza ni se conserven una vez que se completa una solicitud, incluso en presencia de errores de implementación. El Secure Enclave aleatoriza las claves de cifrado del volumen de datos en cada reinicio y no persiste estas claves aleatorias, garantizando que los datos escritos en el volumen de datos no puedan retenerse a través de un reinicio. En otras palabras, existe una garantía exigible de que el volumen de datos se borra criptográficamente cada vez que el procesador Secure Enclave del nodo de PCC se reinicia. El proceso de inferencia en el nodo de PCC elimina los datos asociados con una solicitud al completarse, y los espacios de direcciones que se utilizan para manejar los datos del usuario se reciclan periódicamente para limitar el impacto de cualquier dato que pueda haberse conservado inesperadamente en la memoria.
Finalmente, para que nuestras garantías exigibles sean significativas, también necesitamos protegernos contra la explotación que podría eludir estas garantías. Tecnologías como los códigos de autenticación de puntero y el aislamiento actúan para resistir dicha explotación y limitar el movimiento horizontal de un atacante dentro del nodo de PCC. Las capas de control de inferencia y despacho están escritas en Swift, garantizando la seguridad de memoria, y utilizan espacios de direcciones separados para aislar el procesamiento inicial de las solicitudes. Esta combinación de seguridad de memoria y el principio de menor privilegio eliminan clases enteras de ataques en la pila de inferencia en sí y limitan el nivel de control y capacidad que un ataque exitoso puede obtener.
Sin acceso privilegiado en tiempo de ejecución
Diseñamos Private Cloud Compute para garantizar que el acceso privilegiado no permita a nadie eludir nuestras garantías de cómputo sin estado.
Primero, intencionadamente no incluimos mecan