- Secure Boot es recolza en UEFI, una jerarquia de claus (PK, KEK) i bases de dades (DB, DBX) per garantir que només s'executi microprogramari i bootloaders de confiança.
- La caducitat de certificats del 2011 al 2026 exigeix actualitzar claus i bases de dades per mantenir la protecció de l'arrencada a Windows i Linux.
- El maquinari de microprogramari combina Secure Boot amb actualitzacions signades, arrels de confiança de maquinari, xifratge i monitorització contínua.
- Solucions com FirmGuard i socis experts en sistemes encastats faciliten la gestió remota, la migració a UEFI i la implantació de cadenes d'arrencada segures.
En molts equips i dispositius, el firmware arrenca en silenci cada vegada que prems el botó d'encesa, però en aquest moment depèn que tota la resta sigui fiable o un autèntic colador. Què és el firmware i per a què serveix . La combinació de Secure Boot, UEFI i un bon hardening del firmware marca la diferència entre un sistema que aguanta atacs seriosos i un altre que pot caure per un simple pendrive maliciós.
En aquest article baixarem al fang i explicarem, amb calma però sense embuts, què és Secure Boot, com es relaciona amb el firmware UEFI, quins problemes apareixen amb els certificats que expiren el 2026 i com encaixa tot això amb la seguretat en Windows, Linux i sistemes embeguts. També hi veuràs solucions avançades com la gestió remota del BIOS, la monitorització d'integritat i el paper dels socis experts quan la cosa es complica.
Què és Secure Boot i per què importa tant
Secure Boot és una funció de seguretat integrada al microprogramari UEFI que controla quin programari es pot executar en les primeres fases de l'arrencada. La seva missió és senzilla de dir i difícil de fer bé: que només s'iniciï codi signat i de confiança (bootloaders, controladors UEFI, aplicacions EFI) i bloquejar qualsevol binari que no compleixi les polítiques definides al microprogramari.
A la pràctica, el microprogramari UEFI compara la signatura digital del codi que executarà amb una sèrie de certificats i llistes de signatures emmagatzemades internament. Si la signatura coincideix amb un certificat o hash permès a la base de dades de confiança (DB) , aquest component s'executa; si no, es bloqueja. D'aquesta manera es pretén tallar d'arrel l'execució de bootkits i codi maliciós que intenti enganxar-se a l'arrencada.
Secure Boot va aparèixer de forma massiva amb Windows 8, quan van començar a proliferar amenaces que es carregaven abans del sistema operatiu. El model consisteix en una cadena de confiança : el mateix firmware UEFI valida els seus mòduls interns (com Option ROMs), després comprova el carregador d'arrencada (per exemple, Windows Boot Manager o shim/GRUB a Linux) i, només si tot és acceptat, cedeix el control a aquest bootloader, que alhora valida el bin.
La clau és que la confiança de Secure Boot es defineix mitjançant una política de microprogramari fixada a fàbrica . Aquesta política s'expressa mitjançant un arbre de claus i bases de dades: una clau de plataforma que mana sobre les altres, unes KEK que autoritzen canvis i dues llistes, DB i DBX, que dicten què es permet i què es prohibeix. Gestionar correctament aquest ecosistema és tan important com activar l'opció de Secure Boot al Windows 11 al menú.
Estructura de claus: PK, KEK, DB i DBX
El cor de Secure Boot és una jerarquia de claus i bases de dades de signatures . Entendre-la és fonamental per a qualsevol estratègia de hardening, tant en entorns domèstics com, sobretot, en infraestructures empresarials o de missió crítica.
A la cúspide hi ha la Platform Key (PK) , normalment generada i gestionada pel fabricant del maquinari. Aquesta clau és l'autoritat màxima: qui la posseeixi pot canviar la resta d'elements de Secure Boot, i per això el seu compromís posa en dubte tota la cadena de confiança. Algunes organitzacions substitueixen la PK de fàbrica per una de pròpia per prendre el control de la plataforma.
Un nivell per sota hi trobem les Key Exchange Keys (KEK) , claus que autoritzen l'actualització de les bases de dades DB i DBX. Hi sol haver una KEK de Microsoft, una o diverses del fabricant de l'equip i, en entorns corporatius, KEKs pròpies de l'organització. Qualsevol entitat amb una KEK vàlida està en posició d'afegir o revocar certificats i hashes a les llistes de Secure Boot.
La base de dades de signatures permeses (DB) emmagatzema certificats i hashes de binaris que el microprogramari pot executar a la fase d'arrencada. S'hi inclouen certificats de Microsoft, de l'OEM i, si escau, de l'empresa que controla el parc. Quan el microprogramari analitza un bootloader o un Option ROM, cerca una coincidència en DB per decidir si el carrega.
A la banda oposada hi ha la base de dades de signatures revocades (DBX) , que recull binaris i certificats que ja no s'han de considerar segurs. Microsoft actualitza DBX periòdicament per invalidar bootloaders vulnerables (com es va veure amb casos tipus BootHole) o components que s'han demostrat insegurs. Mantenir DBX al dia és clau per evitar que un binari signat però obsolet segueixi sent una porta dentrada.
Certificats de Secure Boot que caduquen el 2026
Des de la introducció de Secure Boot, pràcticament tots els equips compatibles amb Windows han inclòs un conjunt comú de certificats de Microsoft a KEK i DB . El problema és que part d'aquests certificats es van emetre el 2011 i s'acosten a la data de caducitat, cosa que té implicacions directes sobre la protecció d'arrencada en milions de dispositius.
Concretament, certificats com Microsoft Corporation KEK CA 2011 , Microsoft Windows Production PCA 2011 o Microsoft UEFI CA 2011 tenen dates d'expiració entre juny i octubre de 2026. Cadascú compleix un rol diferent: signar actualitzacions de DB i DBX, el carregador de Windows, bootloaders de tercers.
Per garantir la continuïtat de la seguretat, Microsoft ha emès en 2023 nous certificats que substitueixen els de 2011 : per exemple, Microsoft Corporation KEK 2K CA 2023 com a reemplaçament de la KEK original, Windows UEFI CA 2023 per al bootloader del sistema i certificats actualitzats per a signatures d'aplicacions EFI i Option.
La companyia gestiona de forma centralitzada l'actualització d'aquests certificats a una gran part del parc Windows, de manera molt similar a com distribueix altres pegats de seguretat. Els OEM també publiquen actualitzacions de microprogramari quan és necessari per incorporar els nous certificats o ajustar la configuració de Secure Boot.
Si un dispositiu no arriba a rebre les noves claus abans que caduquin les actuals, continuarà arrencant i rebent actualitzacions de Windows de forma normal, però deixarà de poder aplicar mitigacions específiques per a la fase d'arrencada : no rebrà alguns canvis al Windows Boot Manager, actualitzacions de DB/DBX ni pegats per a vulnerabilitats de baix nivell recent descobert.
Impacte de l'expiració de certificats i accions necessàries
L'expiració dels certificats de 2011 no implica que el teu equip s'hagi de deixar d'encendre, però sí que redueix progressivament la capacitat del sistema per defensar-se davant d'amenaces que afecten l'arrencada . Això pot repercutir, entre d'altres, en escenaris com l'enduriment de BitLocker o l'ús de bootloaders de tercers que depenen de la cadena de confiança de Secure Boot.
Per minimitzar riscos, Microsoft recomana i, en molts casos, automatitza el procés d' actualització de KEK i DB amb els certificats del 2023 . Els administradors de TI i els responsables de seguretat han de comprovar si els dispositius han rebut aquests canvis, especialment en flotes heterogènies amb maquinari antic o firmware que ja no s'actualitza amb tanta freqüència.
La crida a l'acció és clara: revisar l'estat de Secure Boot a cada tipus de dispositiu , identificar si s'utilitzen els certificats antics i planificar l'actualització, i seguir guies per activar l'arrencada segura després d'actualitzar la BIOS . En entorns gestionats, sol ser necessari consultar la documentació específica del fabricant o seguir les guies de “Windows Secure Boot Key Creation and Management Guidance” per integrar correctament les noves claus al procés de desplegament.
En alguns casos, especialment quan s'han personalitzat PK, KEK o DB amb certificats propis de l'organització, l'actualització pot requerir passos manuals i proves curoses per evitar deixar fora de joc bootloaders legítims que no s'hagin confirmat encara amb les claus vigents. Un error de coordinació aquí es pot traduir en sistemes que deixen d'arrencar després de l'aplicació d'un pegat de seguretat.
Secure Boot i Linux: cadena de confiança, shim i GRUB2
En sistemes Linux, la pel·lícula és semblant, però amb les seves particularitats. La majoria de distribucions modernes confien en un component anomenat shim , un petit bootloader signat per Microsoft perquè el firmware UEFI ho accepti de sèrie. Shim actua com a pont: el firmware el carrega gràcies a la signatura de Microsoft i, a partir d'aquí, shim valida GRUB2 i el kernel amb claus específiques de la distribució.
El flux típic a Linux amb Secure Boot té aquesta forma: UEFI valida shim, shim valida GRUB2 i GRUB2 valida el kernel . Cada etapa es basa en firmes digitals i en una política de claus que resideix al mateix shim ia les bases de dades de Secure Boot. Així s'aconsegueix que el fabricant de l'equip no hagi de conèixer per endavant les claus de cada distribució, però es manté el control de quin nucli pot arrencar.
En aquest context, els mateixos elements que vam veure abans segueixen sent essencials: la PK controla qui pot canviar la configuració global de Secure Boot al microprogramari, les KEK decideixen qui pot actualitzar DB i DBX, DB recull les claus admeses (incloent les necessàries per a shim) i DBX emmagatzema les revocacions que bloquegen binaris vulnerables.
El model té avantatges en interoperabilitat, però hi afegeix complexitat operativa. Per exemple, quan apareix una vulnerabilitat crítica a shim oa GRUB2, cal actualitzar ràpidament el bootloader afectat i, en paral·lel, distribuir una entrada a DBX que revoqui les versions antigues . Si es fa malament l'ordre, pots trobar-te amb equips que encara necessiten un shim vell per arrencar, però el binari del qual ha estat revocat.
El resultat és que la gestió correcta de DBX i de les firmes de bootloaders Linux es converteix en una tasca delicada, especialment en entorns on conviuen diverses distribucions, versions LTS i programari de tercers que també participa en l'arrencada (per exemple, gestors de xifratge o hipervisors).
Què protegeix Secure Boot… i què no
Secure Boot està pensat per bloquejar atacs que actuen sobre les primeres fases de l'encesa . Parlem de bootkits que modifiquen el bootloader per carregar el seu propi payload, kernels substituïts per versions malicioses, Option ROMs adulterats que s'executen abans del sistema operatiu o binaris EFI introduïts per guanyar persistència.
En exigir que cada component de la cadena d'arrencada estigui signat i validat, es redueix moltíssim la superfície d'atac per a qui vulgui “amagar-se” sota el sistema operatiu. Un bootloader compromès pot desactivar telemetria, saltar controls d'integritat o plantar rootkits abans que les eines de seguretat es posin en marxa. Secure Boot intenta tancar aquesta via.
També limita parcialment les opcions de l'atacant amb accés físic: ja no n'hi ha prou d'arrencar des d'un USB amb un carregador manipulat, perquè el microprogramari rebutjarà binaris que no estiguin signats amb certificats admesos . Això no significa que la seguretat física deixi d'importar, però sí que puja el llistó per als que pretenguin comprometre un equip aprofitant una badada.
Ara bé, Secure Boot té límits clars. No protegeix davant de vulnerabilitats dins del propi sistema operatiu , ni impedeix que un usuari amb privilegis elevats abusi de funcions legítimes per causar danys. Tampoc evita atacs de xarxa, explotació de serveis o errors de configuració a la capa d'aplicacions.
A més, la història demostra que la cadena d'arrencada mateixa pot ser vulnerable. Shim i GRUB2 han patit errors crítics , com el famós cas BootHole, on una fallada en l'anàlisi de la configuració de GRUB2 permetia manipular l'arrencada sense invalidar la signatura. La resposta a aquests incidents ha estat actualitzar binaris i revocar versions insegures via DBX, cosa que torna a posar al centre la importància d'un manteniment actiu de Secure Boot.
Reptes d'implementació, hardening i manteniment
Gran part dels problemes amb Secure Boot no vénen d'atacs sofisticats, sinó d' equips amb firmware sense actualitzar, llistes DBX obsoletes o claus que ningú no ha revisat des que el maquinari va sortir de la caixa . És a dir, de la pura deixadesa operativa que s'hi acumula amb el temps.
En molts casos, el primer punt de millora és tan simple com aplicar sistemàticament les actualitzacions de UEFI/BIOS que publica el fabricant . Aquestes actualitzacions no només corregeixen bugs, també poden incloure noves funcions de seguretat, millores en la gestió de claus i pegats per a vulnerabilitats del mateix microprogramari.
Un altre front clau és la higiene de claus . Les organitzacions que es recolzen únicament a les PK i KEK de l'OEM i de Microsoft depenen completament dels calendaris d'aquests proveïdors, mentre que els qui gestionen claus pròpies necessiten un inventari clar: quina signa cada clau, quan caduca i quin és el pla de rotació. Perdre el control d'aquest mapa és la recepta perfecta per al caos a l'arrencada.
DB i DBX mereixen un seguiment específic. Una DBX que no s'ha actualitzat en mesos probablement deixa actius binaris que ja s'han declarat insegurs . D'altra banda, una actualització mal provada pot trencar la compatibilitat amb versions antigues de shim o GRUB2. Per això, moltes empreses integren els canvis en DB/DBX al seu cicle normal de gestió de canvis, sotmetent-los a proves prèvies en entorns de staging.
En organitzacions grans, cada vegada és més habitual combinar Secure Boot amb mesures d'arrencada mesurada i suport de TPM . Amb això es registren al TPM els hashes de cada etapa del boot, de manera que es pot testificar remotament que l'equip ha arrencat amb una combinació coneguda i autoritzada de firmware, bootloader i kernel.
Més enllà de l'arrencada: protegir el microprogramari en totes les fases
Per molt potent que sigui Secure Boot, per si sol no n'hi ha prou. La seguretat del microprogramari és un procés continu que inclou configuració, actualitzacions, supervisió i resposta davant d'incidents. La idea és construir capes de protecció que es reforcin mútuament.
Un aspecte essencial és el de les actualitzacions de microprogramari segures . No té sentit escudar-se a Secure Boot si després acceptem flashejar el microprogramari des de qualsevol entorn sense validar signatures, sense protecció davant d'atacs de downgrade o sense un mecanisme de recuperació en cas de fallada. Les actualitzacions han d'estar signades digitalment, aplicar-se seguint un procediment robust i, si és possible, incorporar protecció davant de regressió a versions vulnerables.
També cal aprofitar el maquinari de seguretat disponible: arrels de confiança en maquinari, zones d'emmagatzematge segur de claus, TPM, TrustZone, mòduls segurs externs … Aquestes peces permeten aïllar secrets criptogràfics i fer molt més difícil que un atacant amb accés físic pugui extreure claus o modificar codi sense ser detectat.
Pel que fa a les dades, la combinació d' arrencada verificada més xifrada d'informació sensible és un salt qualitatiu. Si el dispositiu utilitza Secure Boot per garantir que arrenqueu només microprogramari de confiança, podeu lligar el desxifrat de dades a aquest estat verificat. Així, encara que algú copiï la memòria, no tindrà accés al contingut si no és capaç de reproduir la mateixa cadena d'arrencada legítima.
El cicle es tanca amb mecanismes de protecció en temps d'execució: comprovacions periòdiques d'integritat de memòria i microprogramari, watchdogs, registres d'esdeveniments de seguretat relacionats amb errors d'arrencada o intents de modificació i, per descomptat, bloqueig d'interfícies de depuració, lectura protegida de la memòria de programa i controls d'accés adequats al maquinari.
FirmGuard i la gestió remota del BIOS/UEFI
En entorns empresarials i proveïdors de serveis gestionats, gestionar equip a equip la configuració de microprogramari és una pèrdua de temps i una font derrors. Aquí entren solucions com FirmGuard, que ofereix una plataforma centralitzada per assegurar, configurar, monitoritzar i actualitzar el microprogramari del BIOS/UEFI de forma remota.
Un dels seus pilars és la capacitat de configurar remotament opcions crítiques del BIOS/UEFI (SecureConfig) . Això permet als administradors habilitar Secure Boot de manera sistemàtica, ajustar paràmetres de seguretat, desactivar arrencades des de dispositius no autoritzats o aplicar plantilles de configuració endurida sense haver d'anar físicament a cada lloc.
A més, FirmGuard integra funcions de monitorització contínua de la integritat del microprogramari (SecureCheck) . La plataforma vigila els canvis al BIOS/UEFI, detecta modificacions no esperades i alerta quan alguna cosa apunta a possible activitat maliciosa oa un canvi de configuració no autoritzat. En un entorn on el firmware és un objectiu cada cop més desitjable, aquesta visibilitat és or pur.
Per a sistemes que encara funcionen en mode BIOS heretat, FirmGuard afegeix una tercera pota, SecureSense, capaç d'identificar equips que segueixen a Legacy BIOS i facilitar-ne la migració a UEFI, un pas imprescindible per poder utilitzar Secure Boot i altres capacitats modernes de seguretat. Des del punt de vista d'una empresa o un MSP això suposa passar d'un parc heterogeni i difícil de controlar una base més homogènia i defensable.
En conjunt, aquest tipus de solucions no només redueixen el risc d'atacs contra el microprogramari, sinó que aporten un valor afegit clar per a proveïdors de serveis gestionats , que poden diferenciar-se oferint un nivell extra de protecció sota el capó i, de passada, millorar els marges en automatitzar tasques que abans eren manuals i costoses.
Firmware i Secure Boot en sistemes embeguts
Més enllà de PCs i servidors, la seguretat del microprogramari és crítica en dispositius embeguts: controladors industrials, equips mèdics, electrònica de consum, automoció i un llarg etcètera. Aquí les fallades no només es tradueixen en pèrdua de dades, sinó sovint en riscos de seguretat física i responsabilitat regulatòria.
Els usuaris finals d'aquests dispositius normalment no són conscients que a sota hi ha un microprogramari vulnerable. Tot i això, els incidents són molt reals: hi ha hagut retirades massives de dispositius mèdics per problemes de seguretat , com el sonat cas dels marcapassos que es van haver d'actualitzar o reemplaçar per risc d'atac remot. Aquestes situacions impacten en la confiança, la butxaca i la reputació dels fabricants.
Quan el firmware d'un dispositiu embegut es veu compromès, les conseqüències poden ser devastadores: pèrdua de confiança de clients, costos recalls, retards en certificacions (sanitàries, automoció, industrial), impacte a la imatge de marca i, de vegades, interrupcions operatives en infraestructures crítiques.
En aquests entorns, Secure Boot té una importància encara més gran. Implementar una cadena de confiança des del primer byte que s'executa permet assegurar que només el firmware signat pel fabricant (o per una autoritat de confiança) es pugui posar en marxa. A partir d´aquí, cada fase de l´arrencada pot validar la següent: bootloader inicial, bootloader secundari, firmware d´aplicació, kernel d´un sistema operatiu embegut, etc.
Això sí, desplegar Secure Boot en dispositius encastats no és trivial. Es necessita suport maquinari per emmagatzemar claus de forma segura , un segment de codi immutable que actuï com a arrel de confiança i un procés de fabricació capaç de personalitzar cada equip amb les seves claus i certificats sense exposar-los. A plataformes molt limitades, pot ser necessari implementar bootloaders segurs a mida, amb tots els reptes de rendiment, consum i cost que comporta.
Capes addicionals per a un firmware realment robust
Perquè la protecció del microprogramari sigui sòlida, cal pensar en diverses capes. La primera és Secure Boot, però al seu voltant han de conviure mecanismes d‟actualització segura, emmagatzematge protegit, defenses en temps d‟execució i bones pràctiques organitzatives.
A la part d'actualització, tota imatge de firmware o de programari de baix nivell hauria d'estar signada digitalment i, si és possible, protegida davant downgrades . Els sistemes OTA o les actualitzacions locals han de comprovar la signatura abans d'acceptar canvis, i convé comptar amb plans de contingència (còpies de microprogramari de seguretat, modes de recuperació segurs) per evitar “maons” inservibles després d'una fallada, seguint bones pràctiques d' actualitzacions de seguretat de programari.
Lemmagatzematge segur juga un altre paper crític. MCUs modernes, SoCs amb TrustZone, TPMs o elements segurs dedicats permeten protegir claus i dades sensibles perquè ni tan sols algú amb accés físic pugui extreure'ls sense deixar rastre o sense un esforç desproporcionat. Vincular l'accés a aquests secrets a l'èxit de Secure Boot hi afegeix una capa extra de garantia.
Durant l'execució, és fonamental combinar comprovacions periòdiques d'integritat, watchdogs, protecció de memòria (MPU, MMU, lockstep), registres d'intent d'arrencada fallida o canvis sospitosos al microprogramari i, en productes molt crítics, fins i tot sensors físics de manipulació.
Finalment, res d'això no funciona bé si l'organització no adopta pràctiques de desenvolupament segur i gestió de vulnerabilitats : anàlisi d'amenaces, disseny orientat a seguretat, revisions de codi, tests d'intrusió, processos clars de resposta davant d'incidents i un cicle de vida on seguretat i qualitat vagin de la mà. El microprogramari no es pot tractar com una cosa que s'escriu una vegada i s'oblida.
El valor de comptar amb socis experts en firmware i seguretat
Amb tot el que hem vist, és fàcil entendre per què moltes empreses recorren a socis especialitzats en sistemes encastats i ciberseguretat quan necessiten reforçar Secure Boot i la protecció del microprogramari. Aquí no n'hi ha prou de saber programar: cal dominar maquinari, criptografia, processos industrials, normatives i l'ecosistema complet d'atacs i defenses.
Un bon soci aporta experiència pràctica desenvolupant bootloaders, drivers, sistemes embeguts complexos, mecanismes de xifratge i controladors de maquinari , cosa que permet dissenyar solucions de seguretat realment integrades al producte, no pegats d'última hora que només serveixen per complicar el manteniment.
També solen comptar amb playbooks i eines ja provades : mòduls d'arrencada segura reutilitzables, scripts per gestionar claus i certificats, guies de hardening del firmware, pipelins de CI que inclouen signatura de binaris i verificació automàtica, etc. Això estalvia temps i redueix la probabilitat de cometre errors de principiant que després surten caríssims.
La part de ciberseguretat és igualment clau. Equips que viuen al dia en matèria de noves vulnerabilitats, atacs de canal lateral, errors en stacks IoT populars i bones pràctiques de disseny segur ajuden a incorporar la seguretat des de l'arquitectura, en comptes d'intentar pegats al final. Solen treballar amb mentalitat de “security by design”, fent threat modeling i revisions de risc des de la fase de requisits.
Quan, a més, aquest soci està recolzat per certificacions ISO rellevants (ISO 9001, ISO 13485, ISO 26262, etc.) , tens una garantia addicional que els seus processos estan auditats i estructurats. No només és que sàpiguen què cal fer, sinó que tenen procediments formals i traçabilitat, una cosa molt apreciada en sectors regulats com el metge o el d'automoció.
I hi ha un darrer factor menys tècnic però igual d'important: la comunicació i l'empatia . Un bon partner no arriba parlant en argot incomprensible ni imposant solucions impossibles dencaixar en els teus terminis o pressupost. Escolta les restriccions, explica les opcions de forma clara i va ajustant l'enfocament per trobar un equilibri entre seguretat, cost i time-to-market. En projectes de firmware i Secure Boot, aquesta sensació de “anem al mateix vaixell” marca la diferència.
En definitiva, posar en ordre Secure Boot i el hardening del firmware implica combinar una base tècnica sòlida (UEFI, jerarquia de claus, certificats renovats, DB/DBX mantinguts), una operació disciplinada (actualitzacions de firmware, gestió de claus, arrencada mesurada, monitorització) i, quan el context ho exigeix, el suport de solucions. Si tot això es fa bé, el sistema parteix d'una arrencada fiable que reforça qualsevol altra mesura de seguretat que s'apliqui després, des del nucli fins a les aplicacions de més alt nivell.
