Skip to content

Autorización basada en hardware

Cada contraseña es un secreto que una persona debe recordar y, por tanto, un secreto que un atacante puede tomar. Phishing, adivinación de contraseñas, relleno de credenciales, ingeniería social — toda la clase del robo remoto de credenciales existe porque la credencial es algo que un humano sabe.

La autorización basada en hardware elimina el secreto memorizable. El acceso es un emparejamiento criptográfico de dos piezas de hardware físico — el par es el permiso. Cuando un dispositivo solicita acceso, ambos extremos demuestran posesión de material clave complementario; si el par se verifica, la conexión se forma; si no, las máquinas son mutuamente invisibles. Este modelo se denomina Seguridad Geométrica: el acceso está definido por la topología de los emparejamientos activos, no por la transmisión de secretos compartidos. Una máquina que no está emparejada no puede conectarse, independientemente de lo que sepa o presente.

Como la autorización se vincula al hardware y no a un secreto memorizado, no hay tabla de usuarios que vulnerar, no hay formulario de inicio de sesión que suplantar y no hay contraseña que restablecer. La revocación es física: el emparejamiento se corta en la máquina, y toda la clase de ataques de robo remoto de credenciales queda eliminada por estructura, no por política.

Para un comprador regulado la consecuencia es concreta. Una clase de ataque desaparece, y cada evento de acceso es atribuible a un hardware específico en el libro de auditoría. Este artículo cubre cómo funcionan los emparejamientos, los cuatro tipos, las ventajas estructurales sobre las contraseñas y la relación con las capas Diodo y de auditoría.

Dirección planificada — acceso nativo anfitrión a través de internet. Está previsto que os-console se ejecute de forma nativa en el equipo del operador y se empareje con un Archivo Totebox remoto a través de internet público. El transporte previsto es TLS mutuo hacia un endpoint Totebox verificado, con la autorización basada en máquinas sin cambios como límite de acceso. La dirección de refuerzo planificada incluye la revocación de emparejamientos y certificados de dispositivo de corta duración. Nota de honestidad: la ruta actual a través de internet utiliza un túnel de reenvío SSH que aún no verifica la identidad del servidor remoto, por lo que la propiedad de extremo a extremo — el proveedor no puede leer los datos del operador en tránsito — es prevista pero aún no entregada en ese salto; se confirma una vez que el TLS mutuo verificado esté disponible. Véase BRIEF-os-console-rebuild-2030.md Capa 1.

Infraestructura y aplicación: dos capas independientes

La MBA opera en la capa de aplicación, por encima e independientemente de cualquier infraestructura de red. Esta separación es central en la arquitectura.

La Red Privada de PointSav — la malla WireGuard que conecta los nodos de flota — proporciona el transporte en el que se ejecutan los servicios os-*. La pertenencia a la red significa que una máquina puede alcanzar otras máquinas en la malla. No otorga acceso a lo que esas máquinas alojan. Un nodo en la PPN sin emparejamientos MBA puede alcanzar la red; no puede abrir ningún archivo.

Dos capas de seguridad independientes protegen una conexión completa os-consoleos-totebox:

Capa 1 — Pertenencia a la red (PPN): La máquina que se conecta debe ser un par WireGuard registrado. El tráfico de red de pares no registrados se descarta en la capa de red.

Capa 2 — Emparejamiento de aplicación (MBA): El servicio os-* que se conecta debe presentar una huella de clave pública registrada a system-gateway-mba, el componente de pasarela a nivel de aplicación que se ejecuta en el servicio de destino. Si no existe ningún registro de emparejamiento para esa huella, la conexión se rechaza — incluso si la capa de red permitió el tráfico.

Una máquina puede estar en la PPN sin ningún emparejamiento MBA. Puede alcanzar la red; no puede abrir ninguna puerta. Esta es la frontera de soberanía: la parte que posee la infraestructura de red no obtiene acceso a nivel de aplicación a los datos que se ejecutan en ella.

Cómo funciona un emparejamiento

Un emparejamiento es un protocolo criptográfico entre dos máquinas. Los dos extremos poseen material de clave pública y privada complementario. Cuando un Libro Mayor de Comandos se conecta a un Totebox, ambos lados demuestran posesión de la clave correspondiente. Si el par se verifica, la conexión se establece. Si no, las máquinas son invisibles entre sí.

service-pairing gestiona estos emparejamientos con el Noise Protocol 1 y claves de estilo WireGuard 2, derivadas de la atestación de hardware donde la plataforma subyacente lo admite.

Propiedad Comportamiento
Autenticación La clave de emparejamiento en sí — no se transmite ni almacena ninguna contraseña
Autorización La presencia del emparejamiento; el permiso es el par
Revocación El emparejamiento se corta en uno o ambos extremos; las máquinas se vuelven mutuamente invisibles
Vinculación al hardware Donde es posible, la clave privada está sellada en el enclave de hardware del equipo

Los cuatro tipos de emparejamiento

Un Totebox reconoce cuatro tipos de emparejamiento, distinguidos por la relación entre los extremos del par y los datos.

Emparejamiento Extremo Acceso Función
ADMIN Máquina principal del propietario ↔ Totebox Absoluto Clave maestra para el control de VM y hardware, migración y gestión de claves
INPUT Máquina de uso diario del operador ↔ Totebox Lectura / escritura El estado predeterminado — plena agencia sobre datos personales, correo y archivos
USER Máquina de acceso restringido ↔ Totebox Solo lectura Consultar los datos sin modificarlos — auditores, asesores
INTERFACE Agregador de orquestación ↔ Totebox Solo metadatos Visibilidad de la flota sin acceso a registros individuales

El emparejamiento INPUT es el predeterminado y el más potente: el propietario de un Totebox tiene plena agencia por defecto, y las restricciones son degradaciones deliberadas, no configuraciones predeterminadas.

Por qué supera a las contraseñas

Tres ventajas estructurales se siguen de reemplazar las contraseñas con emparejamientos.

Sin base de datos central que vulnerar. No existe ninguna tabla de usuarios en ninguna parte de la arquitectura. Una vulneración exitosa de cualquier componente no produce material de credenciales útil en otro lugar.

Sin superficie de phishing. No se puede engañar a un operador para que escriba un emparejamiento en un formulario de inicio de sesión falso, porque un emparejamiento nunca se escribe. Lo demuestra criptográficamente el propio hardware.

Revocación física. Cuando el acceso de un operador debe terminar, el emparejamiento se corta a nivel de máquina. Una copia conservada del binario es inerte sin el material clave; no hay contraseña que restablecer.

La disciplina de límite

El emparejamiento por sí solo no concede acceso a los datos. Concede la capacidad de intentar el acceso. El Estándar Diodo rige lo que fluye a través de un par establecido; el libro de auditoría registra cada comando y cada respuesta. El par es el prerrequisito; el Diodo y el libro mayor WORM son las puertas.

La combinación — emparejamiento como acceso, Diodo como dirección, auditoría como registro — hace que el sistema sea auditable de extremo a extremo, sin ninguna política de rotación de contraseñas.

Conexiones arquitectónicas

La autorización basada en hardware se conecta a otras tres capas arquitectónicas.

  • Micronúcleo seL4 — el núcleo aplica que los tokens de capacidad no pueden ser falsificados por software que se ejecuta en privilegio de usuario.
  • Seguridad basada en capacidades — el gestor de capacidades emite y revoca tokens vinculados al hardware; el modelo de control de acceso depende de la vinculación al hardware para sus garantías.
  • Libro mayor WORM — cada evento de autorización se registra en el libro de solo adición, un registro verificable externamente de qué hardware accedió a qué recurso y cuándo.
  • system-gateway-mba — el crate de pasarela a nivel de aplicación que aplica los registros de emparejamiento en cada frontera de servicio os-*; el componente que comprueba las huellas de claves entrantes contra el registro de emparejamientos y rechaza las conexiones sin un registro coincidente.

Por qué se rechazó service-auth

Los primeros diseños consideraron service-auth, modelado en un servicio de directorio tradicional, como proveedor de identidad. La decisión se revirtió: un servicio de directorio se estructura en torno a usuarios, contraseñas y jerarquías de grupos — exactamente el modelo que PointSav está reemplazando. service-pairing se creó como la alternativa deliberada, y service-auth se eliminó de la arquitectura antes de escribir código. Véase emparejamiento como permiso.

Véase también

  • diode-standard — el flujo de comandos unidireccional que rige lo que pasa a través de un par establecido
  • worm-ledger-design — el libro mayor de solo adición que registra cada evento de autorización
  • sel4-microkernel-substrate — el micronúcleo seL4 que aplica la integridad de los tokens de capacidad
  • compliance-and-continuous-disclosure — cómo la autorización vinculada al hardware apoya el cumplimiento de prueba continua
  • deployment-patterns — cómo el emparejamiento MBA se aplica en las seis configuraciones de despliegue canónicas
  • ppn-mesh-architecture — la capa de infraestructura de malla WireGuard en la que se ejecutan los servicios os-*; la MBA opera por encima e independientemente de la PPN
  1. Perrin, T. 'The Noise Protocol Framework.' noiseprotocol.org, 2016. https://noiseprotocol.org/noise.html

  2. Donenfeld, J. A. 'WireGuard: Next Generation Kernel Network Tunnel.' NDSS Symposium, 2017. https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/wireguard-next-generation-kernel-network-tunnel/

Important Information

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is a trade name of Woodfine Capital Projects Inc. ("Woodfine"). PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. See TRADEMARK.md in this repository for the full trademark notice.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →