Credenciales y aprovisionamiento

01 · Una identidad que se puede mantener

Del canal protegido al equipo autorizado

El tema 41 explicó cómo verificar al servidor y proteger una conexión. Ahora resolvemos de dónde sale la identidad del dispositivo, quién autoriza su incorporación y qué ocurre cuando una credencial cambia o deja de ser confiable.

Aprovisionar es preparar el equipo con la configuración y el material necesarios para funcionar en una instalación: conectividad, confianza en los servicios, identidad operativa y asociación con recursos. Es un proceso del dispositivo, la aplicación de instalación y la plataforma; no solo una escritura en la memoria flash.

Estar cerca de la placa o conocer su dirección MAC no resuelve todas esas preguntas. Una app de instalación autenticada tampoco convierte en legítimo cualquier equipo que se presente con un número de serie conocido.

02 · Nombre, prueba y permiso

Identificadores y credenciales

Un identificador nombra una entidad. Una credencial y el protocolo que la utiliza permiten acreditar una identidad. Un permiso establece qué puede hacer esa identidad. Guardar device_id=equipo07 no demuestra posesión legítima de equipo07.

Por qué una identidad por equipo

Si todas las unidades comparten el mismo token, extraerlo de una permite suplantar a las demás y dificulta revocar una sola. Con identidades separadas, la plataforma puede limitar permisos y retirar una unidad sin reemplazar necesariamente las credenciales de toda la flota.

La separación reduce el alcance de una pérdida, pero no demuestra que el equipo esté sano. Un dispositivo comprometido puede seguir autenticándose con una clave legítima. Detección, límites de uso y respuesta a incidentes completan el diseño.

Vinculación con la instalación

La relación equipo07 → plantaA se decide mediante un procedimiento autorizado. No se acepta un campo sitio del mensaje como prueba de propiedad. También se controla quién puede mover el equipo a otra organización y qué permisos anteriores deben desaparecer.

03 · Del inventario a la operación

Un alta con etapas verificables

Un proceso posible combina una identidad inicial conocida, una autorización de instalación y una identidad operativa nueva. Los detalles cambian según el producto, pero cada etapa necesita una evidencia verificable y un resultado recuperable.

1. Identificar el equipo esperado: el inventario contiene su referencia y el mecanismo inicial admitido.
2. Autorizar la instalación: el operador puede asociar ese equipo con ese sitio; se controla si ya pertenece a otro.
3. Establecer confianza: equipo, app y servicio verifican a los extremos que corresponden antes de intercambiar secretos.
4. Preparar material operativo: generar la clave en el equipo o emitir una credencial mediante el procedimiento elegido, registrando una transacción.
5. Instalar y comprobar: el dispositivo persiste el material y demuestra que puede usarlo por el canal previsto.
6. Activar y cerrar: la plataforma confirma el cambio, limita o consume la autorización inicial y habilita los recursos permitidos.

La credencial pendiente puede ser aceptada en un punto de confirmación con permisos mínimos; no necesita habilitar todavía la operación general. La prueba de posesión depende del mecanismo: una clave privada se utiliza en el protocolo, sin enviarla al servidor; un token portador requiere protección durante entrega y uso.

La autorización inicial puede ser de un solo uso o seguir otra política explícita de fábrica. En este tema se consume al preparar el primer alta. Una interrupción posterior se resuelve recuperando esa transacción autenticada, no habilitando el mismo código para reclamar cualquier equipo.

04 · Confiar por primera vez

Cómo llega la confianza inicial

Un QR puede contener un ID público, un código secreto o ambos. Fotografiar un código secreto puede transferir su capacidad de uso. El diseño define si el código caduca, si se consume, con qué equipo y propietario se vincula y cómo se recupera una instalación interrumpida. Un número de serie predecible no reemplaza un secreto aleatorio.

Un botón físico puede abrir una ventana de instalación, pero la presencia física es una condición más. No prueba por sí sola la identidad remota ni autoriza transferir la propiedad de un equipo ya asociado. La ventana se cierra al terminar o vencer y no reaparece indefinidamente ante cualquier reinicio.

Como ejemplo de un protocolo estandarizado, BRSKI, RFC 8995, combina identidades de fabricante y autorización para incorporar equipos a infraestructura de claves. El modelo didáctico de este tema no implementa ese protocolo ni sus mensajes.

El instalador también tiene permisos

La app usa una sesión de usuario con alcance limitado. La plataforma verifica el permiso sobre el sitio y el equipo antes de emitir credenciales. Una cuenta de instalador no necesita una clave maestra que permita actuar indefinidamente como cualquier dispositivo.

05 · Estado del lado de la plataforma

Registro y permisos por dispositivo

Un registro de identidad vincula el ID del equipo con su pertenencia, el mecanismo de autenticación, las referencias de credenciales y su estado. La aplicación toma de allí la identidad autenticada que usará para evaluar permisos.

{
  "equipo": "equipo07",
  "sitio": "plantaA",
  "estado": "activo",
  "credencial_ref": "referencia-publica-v2",
  "generacion": 2,
  "permisos": ["publicar:telemetria/equipo07"],
  "alta_ref": "transaccion-ficticia-104"
}

Este documento ilustrativo no contiene claves ni tokens. Una referencia de credencial o un número de generación no son secretos. El sistema real necesita control de acceso al registro, actualización concurrente segura y auditoría; cambiar un campo en un JSON del cliente no modifica la autorización del servidor.

De la autenticación al recurso

La plataforma verifica la credencial, obtiene el principal autenticado y resuelve su equipo y sitio. Después comprueba la ACL para la operación solicitada. No permite que un dispositivo autenticado como equipo07 declare equipo08 en el payload y herede sus permisos.

El alcance de una credencial inicial debería permitir el alta prevista, no publicar órdenes de producción. El alcance de la operativa se limita a los recursos necesarios. Las cuentas administrativas y las credenciales de equipos tienen funciones diferentes.

Auditoría útil

Se registran actor, equipo, sitio, referencia de transacción, generación, transición, resultado y tiempo según la política de registros. Se omiten tokens, contraseñas, claves privadas y códigos iniciales. Los mensajes de error públicos también evitan revelar material sensible o facilitar enumeración innecesaria.

06 · Crear, guardar y usar

Generación y protección de claves

Las credenciales secretas se generan con una fuente apropiada para seguridad. No se derivan de la MAC, la fecha o un contador, ni de un generador pensado solo para simulación. Para claves asimétricas se usa el generador de la biblioteca criptográfica y las condiciones de entropía que documenta la plataforma.

Un ejemplo de token en Python local

El módulo secrets de Python ofrece generación de tokens con aleatoriedad del sistema. El siguiente fragmento muestra una creación con 32 bytes aleatorios; no incluye entrega, almacenamiento ni un servicio de autenticación. No imprime el valor:

import secrets

token = secrets.token_urlsafe(32)
# Entregar únicamente por el canal autorizado al equipo correspondiente.
# Guardar mediante el mecanismo de secretos del servicio y del dispositivo.
# No incluir token en logs, URLs, repositorios ni mensajes de diagnóstico.
del token  # elimina la referencia; no garantiza borrado seguro de la memoria

Es un fragmento para un entorno local con una fuente de aleatoriedad adecuada, sin botón de ejecución en esta página. La longitud y el formato forman parte del diseño del sistema. Generar un buen token no protege una entrega expuesta ni compensa permisos excesivos.

Qué conserva el servidor

En un esquema de clave pública, el verificador puede conservar el certificado o clave pública y metadatos, mientras la clave privada queda en el dispositivo. En un esquema de token, el almacenamiento del verificador depende del protocolo: algunos permiten guardar un resumen criptográfico adecuado, otros necesitan acceso al secreto. No se aplica un hash arbitrario sin revisar cómo se verificará y administrará la credencial.

Una clave incrustada como texto en el sketch, un archivo de configuración versionado o una captura de consola puede terminar en copias del firmware y del proyecto. Separar configuración sensible del código fuente evita parte de esa exposición, pero el producto también debe proteger la copia instalada.

07 · Llevar la política al firmware

Aprovisionamiento en ESP32

Con ESP-IDF se puede implementar recepción de configuración por canales como BLE o SoftAP. La documentación de Wi-Fi Provisioning de ESP-IDF 5.5.1 describe el administrador y las sesiones de aprovisionamiento. Esa referencia está fijada a una versión: se comprueba el componente y API disponibles en la versión del proyecto.

Configurar SSID y contraseña da conectividad, pero no completa el alta ante tu plataforma. El producto elige y configura un modo de seguridad compatible, la prueba inicial correspondiente y el cierre del servicio de configuración. No se deduce que cualquier endpoint BLE o servidor HTTP local esté autenticado.

NVS y material sensible

NVS sirve para persistir valores; usarla no demuestra por sí solo que una credencial quede cifrada. NVS Encryption documenta esquemas de cifrado y requisitos de claves y particiones. La configuración efectiva se verifica para la variante y versión elegidas; una llamada de almacenamiento no activa automáticamente todas las protecciones.

El cifrado de almacenamiento no reemplaza el control de integridad y acceso del sistema ni impide que el firmware autorizado lea lo que necesita usar. Se revisan acceso de depuración, copias de producción y exposición por interfaces de servicio.

La guía de seguridad de Espressif distingue Secure Boot, cifrado de flash y otras protecciones. Secure Boot verifica software autorizado; cifrar flash protege confidencialidad del almacenamiento externo. No son funciones intercambiables. La habilitación de protecciones y eFuses se planifica y prueba para el modelo concreto, con su procedimiento de producción y recuperación.

Secuencia conceptual del firmware

Arranque
  leer y validar el estado persistido
  si hay identidad operativa: intentar el servicio autorizado
  si hay transacción pendiente: recuperar esa transacción autenticada
  si no hay alta: admitir instalación solo bajo la política prevista

Instalación
  establecer sesión de configuración protegida
  verificar autorización y vínculo con el equipo
  preparar material nuevo sin perder el estado recuperable
  persistir y verificar la escritura
  demostrar la nueva identidad al punto de confirmación
  registrar activación y cerrar la ventana de instalación

Es un algoritmo conceptual, no una API ni un sketch listo para grabar. El firmware distingue credenciales de red, material de servidor e identidad cliente. Sus tareas de red tienen plazos y reintentos que permiten mantener el control local incluso si el alta no puede terminar.

08 · Cambiar sin perder el control

Rotación, revocación y retiro

Rotar es sustituir material por otro; revocar es dejar de aceptarlo; retirar es cerrar la vida operativa de una identidad o unidad en el sistema. Una renovación programada y una respuesta a robo de clave no tienen necesariamente el mismo flujo.

Rotación normal

El ejemplo prepara la generación 2 mientras la 1 sigue activa. El equipo instala la nueva y demuestra su uso en la confirmación. Solo entonces cambia la generación aceptada y se revoca la anterior en el registro. La pendiente sirve para confirmar, no para operar. Se conserva información suficiente para resolver un acuse perdido.

En producción se define plazo de solapamiento, vencimiento, limpieza de pendientes y comportamiento de equipos desconectados. El laboratorio omite el reloj para concentrarse en transiciones: puede quedar rotando indefinidamente y no debe copiarse como política temporal de producción.

Ante una credencial comprometida

La rotación normal del ejemplo exige la prueba de la identidad actual y autorización de operador. Ante compromiso, no se confía en esa prueba como única base para recuperar el equipo. Se revoca y se aplica un procedimiento de recuperación independiente, con nueva verificación de propiedad y del estado del dispositivo. El modelo rechaza reutilizar el alta inicial tras revocación.

La revocación del lado servidor no exige que el equipo esté conectado ni que entregue su clave. Su efecto real depende de dónde se consulta la política: se atienden réplicas, cachés, sesiones y conexiones ya abiertas. Cambiar el registro no garantiza que todos los componentes corten una sesión existente en ese mismo instante.

Venta, devolución y baja

Un reset local puede borrar Wi-Fi y datos de la placa sin quitar la asociación del backend ni revocar credenciales copiadas. La transferencia requiere autorización, retirada de permisos anteriores, limpieza del material local según sus garantías y nueva incorporación. El retiro también alcanza inventario, claves, permisos y servicios relacionados.

09 · El alta también puede quedar a medias

Reintentos y cortes de energía

El dispositivo y la plataforma no comparten una escritura atómica. Se necesita un protocolo con identificadores de transacción, pasos persistidos, consultas autenticadas de estado y reintentos controlados. Una respuesta de red perdida no demuestra que la operación no se haya aplicado.

Guardar varios campos uno por uno no demuestra una transición atómica. Una implementación puede usar registros versionados, validación, slots y marcadores de confirmación adecuados al almacenamiento, junto con transacciones y control de concurrencia en el servidor. La solución se prueba cortando energía y red en puntos concretos.

En el modelo, persistencia disponible representa una transacción durable del registro central: o se aplica todo el cambio de estado o se devuelve el anterior. No simula el almacenamiento físico de la placa ni una transacción distribuida. La acción «reiniciar» vuelve a leer ese registro abstracto y conserva la revocación y el consumo inicial.

Las banderas de prueba representan verificaciones ya realizadas por componentes confiables. Ningún cliente real puede enviar prueba=true o operador=true y con eso autorizarse. Tampoco se modelan firmas, generación de claves, transporte, expiración, ACL ni sesiones existentes.

10 · Un modelo con estado

Modelo ejecutable en Python

El registro siguiente corresponde siempre a equipo07 en plantaA. Cada generación es una etiqueta pública que representa una credencial distinta. Su número nunca es suficiente para autenticarse: el flag de prueba resume un mecanismo externo que aquí no se implementa.

aplicar copia el estado recibido y devuelve resultado y estado nuevo. Los rechazos conservan el registro. La revocación administrativa no requiere la prueba de clave del dispositivo, pero sí canal, permiso de operador y persistencia.

from copy import deepcopy


def nuevo():
    return dict(equipo="equipo07", sitio="plantaA", fase="nuevo", actual=0,
                pendiente=0, ultima=0, bootstrapConsumido=False, revocadas=[])


def aplicar(estado, accion, canal=True, operador=True, bootstrap=True,
            identidad=True, prueba=True, persistencia=True, generacion=1):
    e = deepcopy(estado)
    def fin(ok, motivo):
        return dict(estado=e, ok=ok, motivo=motivo)
    if accion == "reiniciar":
        return fin(True, "Reinicio: se conserva el registro durable simulado")
    if accion not in ("alta", "confirmar", "rotar", "autenticar", "revocar", "retirar"):
        return fin(False, "Acción desconocida")
    if not canal: return fin(False, "Falta canal autenticado y protegido")
    if e["fase"] == "retirado":
        return fin(False, "Equipo retirado: requiere otro procedimiento autorizado")
    if accion in ("alta", "rotar", "revocar", "retirar") and not operador:
        return fin(False, "Operador sin autorización para esta acción y este equipo")
    if accion == "alta":
        if e["fase"] != "nuevo" or e["bootstrapConsumido"]:
            return fin(False, "El alta inicial no está disponible")
        if not bootstrap or not identidad:
            return fin(False, "Falla la prueba inicial o su vínculo con equipo y sitio")
        if not persistencia: return fin(False, "No se confirmó la transacción durable")
        e["ultima"] += 1
        e.update(pendiente=e["ultima"], bootstrapConsumido=True, fase="pendiente")
        return fin(True, "Alta preparada; falta demostrar la credencial operativa pendiente")
    if accion in ("confirmar", "autenticar"):
        if not identidad or not prueba:
            return fin(False, "Falla el vínculo de identidad o la prueba de credencial operativa")
        if generacion in e["revocadas"]: return fin(False, "Generación revocada")
        if accion == "autenticar":
            if e["fase"] not in ("activo", "rotando") or generacion != e["actual"]:
                return fin(False, "La generación no está activa para operar")
            return fin(True, "Identidad operativa aceptada; la ACL se evalúa por separado")
        if e["fase"] == "activo" and generacion == e["actual"] and e["pendiente"] == 0:
            return fin(True, "Confirmación ya aplicada; respuesta idempotente")
        if not e["pendiente"] or generacion != e["pendiente"]:
            return fin(False, "No corresponde a la generación pendiente")
        if not persistencia: return fin(False, "No se confirmó la transacción durable")
        if e["actual"]: e["revocadas"].append(e["actual"])
        e.update(actual=e["pendiente"], pendiente=0, fase="activo")
        return fin(True, "Nueva generación activa; la anterior deja de aceptarse")
    if accion == "rotar":
        if e["fase"] != "activo":
            return fin(False, "La rotación requiere estado activo sin otra rotación pendiente")
        if not identidad or not prueba or generacion != e["actual"]:
            return fin(False, "La rotación normal requiere prueba de la identidad activa")
        if not persistencia: return fin(False, "No se confirmó la transacción durable")
        e["ultima"] += 1
        e.update(pendiente=e["ultima"], fase="rotando")
        return fin(True, "Rotación preparada; la generación actual sigue activa hasta confirmar")
    # Revocación/retiro administrativos: no exigen la clave del dispositivo.
    if not persistencia: return fin(False, "No se confirmó la transacción durable")
    for v in (e["actual"], e["pendiente"]):
        if v > 0 and v not in e["revocadas"]: e["revocadas"].append(v)
    e.update(actual=0, pendiente=0, fase="retirado" if accion == "retirar" else "revocado")
    return fin(True, "Retiro registrado; no admite el alta inicial" if accion == "retirar"
               else "Identidades operativas revocadas en este registro")


estado = nuevo()
comprobaciones = 0


def paso(nombre, accion, esperado, **cfg):
    global estado, comprobaciones
    anterior = deepcopy(estado)
    r = aplicar(estado, accion, **cfg)
    assert r["ok"] == esperado, nombre
    assert estado == anterior, "La función no debe modificar el argumento"
    if not esperado: assert r["estado"] == anterior, "Rechazo sin cambios"
    estado = r["estado"]
    assert not estado["actual"] or estado["actual"] not in estado["revocadas"]
    assert not estado["pendiente"] or estado["pendiente"] not in estado["revocadas"]
    comprobaciones += 1
    print(f'{nombre:29} {"OK" if r["ok"] else "rechazo previsto":17} {estado["fase"]}')


paso("Canal no verificado", "alta", False, canal=False)
paso("Operador no autorizado", "alta", False, operador=False)
paso("Prueba inicial inválida", "alta", False, bootstrap=False)
paso("Sitio/equipo incorrectos", "alta", False, identidad=False)
paso("Falla de persistencia", "alta", False, persistencia=False)
paso("Reservar generación 1", "alta", True)
paso("Repetir alta inicial", "alta", False)
paso("Pendiente no opera", "autenticar", False)
paso("Confirmar sin prueba", "confirmar", False, prueba=False)
paso("Confirmar otra generación", "confirmar", False, generacion=2)
paso("Confirmación no persistida", "confirmar", False, persistencia=False)
paso("Activar generación 1", "confirmar", True)
paso("Repetir confirmación", "confirmar", True)
paso("Operar generación 1", "autenticar", True)
paso("Rotar sin permiso", "rotar", False, operador=False)
paso("Rotar sin prueba actual", "rotar", False, prueba=False)
paso("Preparar generación 2", "rotar", True)
paso("No duplicar rotación", "rotar", False)
paso("Actual sigue operando", "autenticar", True)
paso("Nueva todavía no opera", "autenticar", False, generacion=2)
antes = deepcopy(estado)
paso("Reinicio conserva pendiente", "reiniciar", True)
assert estado == antes
paso("Activar generación 2", "confirmar", True, generacion=2)
paso("Anterior revocada", "autenticar", False)
paso("Operar generación 2", "autenticar", True, generacion=2)
paso("Revocar sin permiso", "revocar", False, operador=False)
paso("Revocación no persistida", "revocar", False, persistencia=False)
paso("Revocar sin clave del equipo", "revocar", True, prueba=False)
paso("Generación 2 revocada", "autenticar", False, generacion=2)
paso("No reusar bootstrap", "alta", False)
antes = deepcopy(estado)
paso("Reinicio conserva revocación", "reiniciar", True)
assert estado == antes
paso("Retirar equipo", "retirar", True)
paso("Retirado no admite alta", "alta", False)
print(f"\n{comprobaciones} escenarios superados; sin claves reales.")

Los 32 escenarios verifican el resultado esperado, la ausencia de cambios al rechazar y la separación entre generaciones activas y revocadas. Dos comparaciones adicionales comprueban que el reinicio simulado conserva el registro.

11 · Acciones sobre un registro ficticio

Laboratorio de identidad operativa

Aplicá una acción por vez sobre equipo07 en plantaA. La generación presentada es un número de referencia; la prueba de credencial se controla por separado. No ingreses contraseñas ni tokens. El estado vive en esta pestaña y no persiste al recargar la página.

Recorrido guiado

1. Con las condiciones iniciales, prepará el alta. Aparece la generación 1 pendiente y se consume la autorización inicial. Todavía no hay generación operativa.
2. Intentá autenticar con 1: se rechaza. Confirmá 1 y luego autenticá: ahora se acepta la identidad; los permisos de la operación siguen fuera del modelo.
3. Repetí la confirmación de 1. Se reconoce que ya fue aplicada, sin emitir otra credencial. Esta idempotencia sirve para un acuse perdido.
4. Elegí preparar rotación con generación 1. Queda 2 pendiente y 1 actual. Intentá rotar de nuevo: no se crea una segunda pendiente.
5. Autenticá con 1 y después con 2: la actual opera, la pendiente no. Simulá reinicio y observá que se conserva la transición.
6. Confirmá 2 con persistencia desactivada. Se rechaza y permanece 1 actual. Restaurá persistencia y confirmá 2: 1 pasa a revocadas.
7. Intentá autenticar con 1. Aunque la prueba esté marcada válida, esa generación ya no se acepta. Con 2 la identidad sigue activa.
8. Quitá la autorización del operador e intentá revocar: se rechaza. Restaurala, desmarcá la prueba operativa y revocá: la administración no necesita la clave del equipo para darlo de baja.
9. Probá alta y autenticación después de revocar. El registro no reabre el mecanismo inicial ni acepta la generación revocada. Un reinicio tampoco cambia eso.
10. Retirá el equipo. No se reactiva mediante alta. «Nuevo escenario ficticio» crea otro ejercicio desde cero; no representa un reset físico ni una función del sistema de producción.

Podés desactivar canal, vínculo de identidad o pruebas para observar qué acción los necesita. La prueba inicial corresponde al alta; la operativa, a confirmación, autenticación y rotación normal. Reiniciar solo consulta el registro simulado y no requiere un canal remoto.

12 · Diseñar y verificar el proceso

Método de implementación

1. Definí identidades: equipo, usuario instalador, sitio y servicio.
2. Elegí el mecanismo inicial: origen de confianza, prueba y límites de uso.
3. Modelá la asociación: quién puede reclamar, transferir, recuperar y retirar cada unidad.
4. Separá la identidad operativa: material por equipo y permisos mínimos.
5. Protegé generación, entrega y almacenamiento: también en fábrica, soporte y copias.
6. Persistí transacciones: referencias, control de concurrencia y recuperación de pasos interrumpidos.
7. Probá la rotación: credencial nueva, confirmación, acuse perdido y retirada de la anterior.
8. Probá revocación y retiro: incluyendo sesiones abiertas, cachés y dispositivos desconectados.
9. Medí y auditá: tiempos, reintentos y resultados, sin registrar secretos.

13 · Práctica guiada

Predecí antes de comprobar

1. Una clave para toda la flota

Un lote de mil placas comparte un token operativo y se extrae de una. ¿Se puede revocar solo esa unidad usando únicamente ese token como identidad?

2. Instalador válido, sitio incorrecto

El instalador inició sesión, pero solo administra plantaB y solicita asociar equipo07 con plantaA. ¿Basta su autenticación?

3. Generación reservada

El alta preparó la generación 1, pero el equipo no la confirmó. ¿Puede operar con ella en el modelo?

4. Acuse de activación perdido

La plataforma activó 1 y se perdió la respuesta. ¿Qué debe ocurrir al repetir su confirmación válida?

5. Cambio sin persistencia

Está activa 1 y pendiente 2. Falla la transacción que confirma 2. ¿Qué estado devuelve el modelo?

6. Revocación de un equipo desconectado

El equipo no responde y se sospecha robo de su token. ¿La plataforma debe obtener su clave antes de revocar?

7. Reset y propiedad

Un botón borra el SSID local. ¿Eso demuestra que el equipo quedó libre para otro propietario?

8. Una clave privada en el servidor de instalación

El equipo genera su par de claves. El servidor pide la clave privada para «verificar que existe». ¿Es necesaria esa entrega?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 43?

Antes de avanzar, dibujá el alta de una unidad y marcá quién autoriza cada paso, dónde queda el estado y cómo se recupera un corte. Después explicá cómo se rotará, revocará y retirará su identidad sin depender de una clave compartida por toda la flota.

En el próximo tema, Actualización remota (OTA), estudiamos cómo descargar y aplicar firmware nuevo por la red, con verificación y recuperación ante fallas.