AES Encrypter - Detalle

Sobre el Proyecto

PCProtector es un sistema de protección de estación de trabajo basado en la presencia de un dispositivo USB autorizado como “llave física”, diseñado para restringir el acceso y forzar bloqueo cuando el token no está conectado o no valida.

Visión del producto

Evolucionar hacia una solución robusta “endpoint lock & unlock”, con administración simple, huella verificable del dispositivo USB, secretos protegidos localmente (DPAPI) y un flujo de operación consistente (modo vigilancia / modo llave).

Para quién está pensado

Está pensado para usuarios individuales, pymes y entornos semi-controlados (oficinas, depósitos, locales, notebooks corporativas, equipos compartidos) donde el riesgo principal no es un atacante sofisticado de laboratorio, sino:

Acceso indebido por terceros cercanos (empleados, visitas, familiares);
pérdida/robo de una notebook con sesión activa o reanudable;
uso no autorizado fuera de horario o sin supervisión.

Valor que aporta

El valor que aporta es claro: convertir el acceso a Windows en una experiencia “key-based”, con una capa adicional persistente (servicio) que opera incluso si la app no está abierta, y una pantalla de bloqueo propia que centraliza la validación del token y la credencial.

Lenguajes

.NET / C#

Tecnologías

AES
DPAPI
Windows Services
WinForms
Criptografía

Repositorio

(Recientemente colocados públicos)

Administrator

0 Stars
1 Forks

Service

0 Stars
1 Forks

CommonLib

0 Stars
1 Forks

CommonLib:

Ver Código

Qué Problemas Resuelve

Dolor específico que ataca

La necesidad de garantizar que el equipo sólo sea utilizable si está presente un factor físico (USB específico) y/o una clave asociada, reduciendo la exposición a accesos casuales o oportunistas.

Situación previa sin la solución

En un esquema tradicional, el acceso depende sólo de:

contraseña de Windows (que puede compartirse);
bloqueo automático por inactividad (que puede ser evadido con reanudación desde suspensión);
sesión ya iniciada (equipo desbloqueado);
reanudación desde suspensión;
falta de control post-login (una vez adentro, no hay “segunda barrera”).

Impacto real de implementarlo

Disuasión inmediata: sin el USB, el usuario queda bloqueado.
Control continuo (según modo): si se desconecta el token, el sistema reacciona.
Menos fricción que MFA online: no depende de red ni de servicios externos.
Operación persistente: un servicio monitorea eventos críticos (inicio/desbloqueo/estado de sesión) y dispara el flujo de bloqueo.

Explicación Técnica

Stack detallado

.NET / C#
Windows Service (servicio residente) para verificación y reacción automática.
WinForms para:

PCProtectorAdministrator (administración/configuración)
LockScreenForm (pantalla de bloqueo integrada en la app, invocable por parámetro --lock)

Librería compartida (CommonLib) para centralizar utilidades comunes (validación USB, criptografía, helpers).
Criptografía:

Uso de AES para cifrar/descifrar secretos o material sensible.
Protección adicional con DPAPI (protección ligada al usuario/máquina) para endurecer el almacenamiento local del “key material”.

Persistencia local (AppData) con archivos de configuración:

key (secreto protegido)
mode (modo de funcionamiento)
path (ruta del ejecutable administrador para que el servicio lo invoque sin hardcodear)

Endurecimiento Windows (hardening local):

carpeta oculta
potencial restricción por ACLs para dificultar acceso directo a los secretos fuera del flujo de la aplicación.

Organización lógica de componentes

Service (PCProtectorService)

Responsable de operar en segundo plano, detectar condiciones de riesgo (USB ausente, eventos de desbloqueo, etc.) y ejecutar acciones: lanzar LockScreen cuando corresponde.

Administrator (PCProtectorAdministrator)

Responsable de la configuración inicial y cambios:

seleccionar USB autorizado;
definir contraseña/clave;
guardar modo;
generar/actualizar archivos clave;
detectar dinámicamente unidades USB conectadas;
exponer LockScreenForm si se invoca con --lock.

CommonLib

Encapsula piezas reutilizables:

USBValidator (criterio de validación del token: identidad del USB + disponibilidad IsReady)
AesHelper / utilidades de cifrado
helpers generales

Flujo interno de funcionamiento

Configuración desde Administrator:

el usuario registra el USB autorizado
se almacena el secreto (cifrado AES + endurecido con DPAPI)
se define el modo (vigilancia continua / llave de acceso)
se guarda la ruta del administrador (path) para invocación desde el servicio

Ejecución persistente:

el servicio corre con Windows
ante eventos relevantes (por ejemplo, desbloqueo de sesión o chequeo periódico según modo), el servicio ejecuta validación del USB vía CommonLib.USBValidator

Reacción ante ausencia:

si el token no está o no valida, el servicio lanza PCProtectorAdministrator.exe --lock
LockScreenForm bloquea la interacción hasta que:

se detecta el USB autorizado y/o
se valida la clave necesaria (según tu diseño del modo)

Autocierre / desbloqueo:

al detectar el USB correcto, la pantalla de bloqueo se cierra automáticamente y devuelve control.

Seguridad

AES protege el contenido lógico (confidencialidad).
DPAPI agrega un “segundo candado” atado al contexto local (usuario/máquina), reduciendo valor de exfiltrar archivos.
ACLs + ocultamiento elevan el costo de manipulación directa.
El diseño separa:

enforcement (servicio) de
UX/configuración (WinForms),
con lógica crítica compartida en CommonLib para evitar duplicación y divergencia.

Arquitectura del Sistema

Flujo de Arquitectura General

Galería de Evidencia

Estado del Desarrollo

Roadmap

v0.9-pre_release

Actualmente estamos trabajando en la optimización de la base de datos y preparando el lanzamiento de la v1.0.

Arquitectura modular

Separación en tres componentes:

PCProtectorService
PCProtectorAdministrator
CommonLib

Eliminación de lógica duplicada mediante centralización en librería común.

Modelo de funcionamiento definido

Implementación conceptual de:

Modo Vigilancia Continua
Modo Llave de Acceso

Flujo --lock para invocar la pantalla de bloqueo desde el servicio.

Persistencia estructurada

Archivos separados en AppData:

key
mode
path

Eliminación de rutas hardcodeadas (el servicio lee path dinámicamente).

Validación USB

Clase USBValidator desacoplada.
Uso de IsReady para robustez.
Detección dinámica de unidades USB en la app.

Pantalla de bloqueo funcional

LockScreenForm integrada.
Cierre automático al detectar USB autorizado.

Cosas a realizar

Realizar un correcta comunicación entre PCProtector Service y Administrator:

Objetivo

Implementar un mecanismo de comunicación robusto entre PCProtectorService y PCProtectorAdministrator, permitiendo que el servicio pueda:

Disparar la pantalla de bloqueo (LockScreenForm)
Mantener sincronizado el estado del sistema

Esto se espera desde el arranque del sistema, no esperando a que el usuario tenga que siempre ejecutar el Administrator.

Problema Actual

Actualmente, la aplicación funciona correctamente cuando el Administrator está ejecutándose, ya que en ese contexto sí puede interactuar con el servicio.

Sin embargo, al reiniciar el sistema ocurre lo siguiente:

El Servicio de Windows inicia correctamente
El servicio detecta el estado del USB
Pero no puede ejecutar el Administrator dentro de la sesión del usuario activo

Esto sucede debido a una limitación estructural del sistema operativo Windows:

Session 0 Isolation

Los Servicios de Windows se ejecutan en Session 0, mientras que las aplicaciones de usuario se ejecutan en sesiones interactivas separadas.

Por diseño de seguridad:

Un servicio no puede mostrar interfaz gráfica directamente.
No puede lanzar procesos interactivos en la sesión del usuario sin mecanismos específicos.
No puede simplemente “ejecutar un .exe” esperando que aparezca en pantalla.

Esta restricción no es un error del proyecto, sino una política de seguridad del sistema operativo.

Próxima Etapa

Voy a implementar IPC mediante Named Pipes, permitiendo así:

Comunicación bidireccional
Envío de comandos (LOCK, UNLOCK, STATUS)
Evitar dependencia de archivos compartidos
Mantener arquitectura limpia y profesional

Nota:

El desafío actual no es funcional sino arquitectónico. La lógica del sistema ya está correctamente implementada. El siguiente salto evolutivo consiste en resolver la comunicación interproceso bajo las restricciones del modelo de seguridad de Windows.

Instalación y Uso Local

Actualmente el proyecto se encuentra en etapa de desarrollo y todavía no cuenta con instalador / ejecutables finales. Para ejecutarlo localmente, el flujo recomendado es correrlo desde Visual Studio, ya que se compone de tres proyectos relacionados: PCProtectorAdministrator, PCProtectorService y la librería compartida CommonLib.

Requisitos

Windows 10/11
Visual Studio 2022 (o Rider) con workload de desarrollo .NET Desktop
.NET SDK instalado (según el target del proyecto)
Permisos de administrador para instalar/ejecutar el servicio

Instalación (modo desarrollo)

# Clonar el repositorio
    # Administrator:
git clone https://github.com/JESMexe/PCProtectorAdministrator.git
    # Service:
git clone https://github.com/JESMexe/PCProtectorService.git
    # CommonLib:
git clone https://github.com/JESMexe/CommonLib.git

# Abrir la solución en Visual Studio o Rider
#    y restaurar dependencias NuGet
#    Build > Restore NuGet Packages

# Verificar referencias (Muy importante)
#    PCProtectorAdministrator → referencia a CommonLib
#    PCProtectorService       → referencia a CommonLib

Ejecución

El sistema se compone de un servicio (enforcement) y una aplicación de administración (UI + LockScreen). En desarrollo se recomienda este orden:

1) Ejecutar PCProtectorAdministrator

Configurar el USB autorizado y el modo de funcionamiento desde la UI.
El Administrator genera y guarda la configuración local (por ejemplo: key, mode, path).

2) Ejecutar / instalar PCProtectorService

Levantar el servicio desde Visual Studio (modo Debug) o instalarlo manualmente para pruebas.
El servicio lee la configuración y, ante ausencia del USB autorizado, intenta disparar la pantalla de bloqueo.

Uso del LockScreen

Para pruebas, el lockscreen puede ejecutarse manualmente iniciando el Administrator con el parámetro:

PCProtectorAdministrator.exe --lock

Estado actual de instalación

El proyecto aún no cuenta con un instalador final porque se está finalizando la comunicación entre el servicio y la UI bajo las restricciones de seguridad de Windows (Session 0 Isolation). Una vez completada esa integración, se publicará un instalador para una ejecución màs simple.