Bootstrapping seguro para IoT

Boo s apping segu o pa a IoT
G ado en Ingenie ía In o má ica
Con oca o ia: Julio 2025
T abajo Fin de G ado
Au o : Jose An onio López Sola
Tu o : An onio Fe nando Ska me a Gómez
Co u o : Sa a Nie es Ma heu Ga cía
29 de Junio de 2025
Boo s apping segu o pa a IoT
Au o
Jose An onio López Sola
Tu o
An onio Fe nando Ska me a Gómez
Ingenie ía de la In o mación y las Comunicaciones
Co u o
Sa a Nie es Ma heu Ga cía
Ingenie ía de la In o mación y las Comunicaciones
G ado en Ingenie ía In o má ica
Mu cia, 29 de Junio de 2025
Ag adecimien os
Es e abajo supone el pun o inal a mi e apa como es udian e del g ado de ingenie-
ía in o má ica y, con ello, la ob ención de un í ulo que me ac edi a como ingenie o
in o má ico. Habe cumplido es e obje i o no hab ía sido posible sin el apoyo de las
pe sonas que me odean. Es po ello po lo que me gus a ía dedica les unas palab as:
A mi amilia, g acias po apoya me y escucha me siemp e que lo he necesi ado. Vues-
os consejos han sido ai e esco en mis peo es momen os.
A mi pa eja, g acias po en ende me cuando ni yo mismo lo hacía, siemp e has es-
ado ahí cuando lo he necesi ado. Admi o la paciencia y comp ensión que has enido
conmigo.
A mi abuelo, g acias po se de los p ime os en en ende el es ue zo que es aba ha-
ciendo. Tus ánimos es án siemp e p esen es en mí.
A mi amigo F an, nunca pod é ag adece e lo su icien e el apoyo que me has dado.
A mi amigo Ja ie , no puedo es a más eliz de habe compa ido con igo oda mi
ida académica.
A mis amigos, g acias po o ece me una ía de escape y di e sión que me ayudase
a desconec a de los es udios cuando e a necesa io.
A los amigos que he hecho en la uni e sidad, es a e apa ha sido más di e ida g acias
a ues a compañía. El año que compa imos en No uega jamás lo ol ida é.
Po úl imo, ag adece a odas aquellas pe sonas que han pa icipado en el desa o-
llo de es e abajo. G acias al p o eso Ra ael Ma ín po guia me en la elección del
TFG. G acias a Sa a Nie es, Gilson, José Manuel y Ped o, po p opo ciona me ayuda
y ma e ial que me acili ase abo da es e p oyec o. G acias al p o eso An onio Fe -
nando Ska me a po di igi es e abajo, es oy muy ag adecido de que en endiese mi
si uación pe sonal de es e año y me p opo cionase un abajo que se adap ase a es as
ci cuns ancias.
Decla ación i mada sob e o iginalidad
del abajo
D./Dña. Jose An onio López Sola, con DNI 49173017Y, es udian e de la i u-
lación de G ado en Ingenie ía In o má ica de la Uni e sidad de Mu cia y au o
del TF i ulado “Boo s apping segu o pa a IoT”.
De acue do con el Reglamen o po el que se egulan los T abajos Fin de G ado
y de Fin de Más e en la Uni e sidad de Mu cia (ap obado C. de Gob. 30-04-2015,
modi icado 22-04-2016 y 28-09-2018), así como la no ma i a in e na pa a la o e a,
asignación, elabo ación y de ensa de los T abajos Fin de G ado y Fin de Más e de
las i ulaciones impa idas en la Facul ad de In o má ica de la Uni e sidad de Mu cia
(ap obada en Jun a de Facul ad 27-11-2015)
DECLARO:
Que el T abajo Fin de G ado p esen ado pa a su e aluación es o iginal y de elabo a-
ción pe sonal. Todas las uen es u ilizadas han sido debidamen e ci adas. Así mismo,
decla o que no incumple ningún con a o de con idencialidad, ni iola ningún de echo
de p opiedad in elec ual e indus ial.
Mu cia, a 29 de Junio de 2025
Fdo.: Jose An onio López Sola
Au o del TF

Resumen
En la ac ualidad, la p esencia de disposi i os In e ne o Things (IoT) en nues a
sociedad es á en aumen o, pudiendo encon a los p ác icamen e en cualquie en o no.
Su uso, aunque apo a g andes bene icios, ambién ae consigo una se ie de e os
a los que se debe hace en e. Es os se deben p incipalmen e a dos ca ac e ís icas
de los disposi i os IoT: la posibilidad de maneja in o mación sensible y su capacidad
pa a in e ac ua con el en o no en el que es án desplegados. Po ello, se hace necesa io
p es a especial in e és a la secu ización de los disposi i os, lle ando a la búsqueda de
un modelo de ges ión que pe mi a asegu a su co ec o uncionamien o.
El obje i o del abajo es es udia cómo soluciona es e p oblema. Pa a ello, se ha
es udiado el modelo de ges ión de la segu idad que es á siendo plan eado en la Uni-
e sidad de Mu cia, con el p oyec o aC i e sEcu i y oR connecTed de Ices liFecYcles
(CERTIFY). Dicho modelo busca p o ege a los disposi i os du an e odo su ciclo de
ida, siendo una de las a eas de mayo impo ancia el p oceso de a anque, al que
se conoce como boo s apping. Es e p oceso es el aspec o cen al de es e abajo. Su
obje i o es pe mi i a los disposi i os ob ene la in o mación necesa ia pa a pode a-
baja de o ma segu a en su en o no. Pa a consegui es o, el boo s apping incluye,
en e o os aspec os, ealiza a eas de au en icación y au o ización, que ga an icen
que los disposi i os desplegados en el en o no son los co ec os y que las acciones que
se les pe mi e ealiza es án limi adas bajo cie os c i e ios. Además, el boo s apping
busca deja p epa ados a los disposi i os pa a que puedan ecibi ac ualizaciones que
man engan el ni el de segu idad con el paso del iempo. El cómo ealiza es as ac ua-
lizaciones ambién es es udiado en el modelo mencionado, y en es e abajo se abo da
como aspec o secunda io.
Una ez es udiada la p opues a de la Uni e sidad de Mu cia, el abajo p opone una
P oo o Concep (PoC) con el obje i o de pone a p ueba cie os aspec os del modelo.
En conc e o, se busca ealiza el p oceso de boo s apping de un disposi i o IoT y as
es e, aplica polí icas de compo amien o que limi en/con olen las acciones del dispo-
si i o. Dichas polí icas son ob enidas de iche os que siguen el es ánda Manu ac u e
Usage Desc ip ion (MUD). Pa a la ealización de la PoC se u iliza como disposi i o
IoT una Raspbe y Pi 3 Model B.
ii
Figu a 1: Escena io IoT p opues o
La igu a 1mues a el escena io IoT que se plan ea en es e abajo, así como los di e-
en es componen es necesa ios pa a su despliegue. En pa icula , las en idades Boo s-
apping Agen yBoo s apping-Se e son las enca gadas de pe mi i el p oceso de
boo s apping del disposi i o IoT, incluyendo su au en icación. Po su pa e, las en i-
dades En o cemen and Recon igu a ion Agen (ERA), De ice and Domain Manage
(DDM), MUD Manage y MUD Se e se enca gan de aplica polí icas de compo a-
mien o, de inidas en un iche o MUD, sob e el disposi i o.
El esul ado de la PoC o ece un escena io que pe mi e ges iona disposi i os IoT,
secu izando su con igu ación inicial median e el p oceso de boo s apping, y e o zán-
dola con la aplicación de polí icas de segu idad una ez que el disposi i o ha iniciado
sus ope aciones. La solución plan eada ambién p opo ciona bene icios al p oyec o en
el que se basa, CERTIFY; al habe hecho uso de componen es desa ollados en dicho
p oyec o, se ha podido de ec a cie os e o es en las implemen aciones y subsana los.
Además, el abajo ealizado incluye una e aluación de los iempos de ejecución de
las p incipales ac i idades que se ealizan en la PoC desa ollada. Se es udia an o
el iempo empleado pa a comple a el p oceso de boo s apping como el iempo ne-
cesa io pa a aplica polí icas de compo amien o. El p incipal esul ado ob enido es
que el boo s apping es un p oceso mucho más pesado, equi iendo ap oximadamen e
seis eces el iempo que necesi a la aplicación de polí icas de segu idad en el disposi i o.
iii
Aunque la PoC plan eada no abo da la o alidad del p oyec o CERTIFY, eniendo
así cie as limi aciones, supone un buen pun o de pa ida pa a comp ende el modelo de
ges ión del ciclo de ida de disposi i os IoT que p opone dicho p oyec o. En pa icula ,
pe mi e ene una isión conc e a de los concep os con los que se debe abaja y
p opo ciona una base sob e la que pode a anza en u u as mejo as.
Ex ended Abs ac
Nowadays, he numbe o In e ne o Things (IoT) de ices is cons an ly inc easing.
In ac , we can ind hese de ices almos e e ywhe e. Al hough hese a e ac s a e e y
use ul, hei own na u e is ela ed o some challenges ha we should con on . Fo
example, some IoT de ices can in e ac wi h hei en i onmen , while o he s a e ma-
naging sensi i e in o ma ion o e en doing bo h hings a he same ime. This na u ally
highligh s he impo ance o secu i y in IoT sys ems.
To add ess his conce n, we ha e s udied a model o managing IoT de ices ha
is cu en ly being de eloped a he Uni e si y o Mu cia wi hin he Eu opean p ojec
aC i e sEcu i y oR connecTed de Ices liFecYcles (CERTIFY). This model p oposes
an app oach o managing secu i y in IoT de ices; i s goal is o manage hei comple e
li ecycle, ensu ing ha hey a e wo king in a secu e way. As pa o his p ocess, one
o he main asks is he secu e boo o boo s apping o he de ice, which is indeed he
main ocus o his wo k. I s pu pose is o allow de ices o ob ain he necessa y da a
o ope a e secu ely in hei en i onmen . To do his, boo s apping includes, among
o he aspec s, pe o ming au hen ica ion and au ho iza ion asks o ensu e ha he
deployed de ices a e allowed o be in such en i onmen , and hei ac ions a e es ic-
ed o a speci ic c i e ion. Mo eo e , boo s apping p epa es he de ices o be able o
ecei e upda es ha main ain hei secu i y le el du ing hei ope a ional pe iod. The
p ocedu e o ca ying ou hese upda es is also s udied wi hin he men ioned model,
and in his wo k, i is add essed as a seconda y aspec .
Once he p oposal om he Uni e si y o Mu cia and he associa ed echnologies
ha i equi es ha e been s udied, he wo k p esen s a P oo o Concep (PoC) wi h
he pu pose o es ing ce ain aspec s o he model. In pa icula , he PoC pe o ms he
boo s apping o an IoT de ice and ies o apply some beha iou al policies o es ic /-
con ol he allowed ac ions o he de ice. These policies a e de ined in iles ha ollow
he Manu ac u e Usage Desc ip ion (MUD) s anda d. Fo he es ing, a Raspbe y Pi
3 Model B has been used as he IoT de ice.
To ca y ou his wo k, se e al componen s p e iously de eloped wi hin he ame-
wo k o he CERTIFY p ojec we e eused. This app oach allowed us o implemen he
scena io mo e efficien ly and ocus on alida ing he key unc ionali ies de ined by he
model. De eloping a comple e IoT en i onmen om sc a ch would ha e been a highly
complex and ime-consuming ask, so he euse o exis ing elemen s was bo h p ac ical

Índice gene al
1. In oducción 1
2. Es ado del a e 5
2.1. Boo s apping de disposi i os IoT . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Modelo de boo s apping CoAP-EAP ............... 6
2.1.1.1. Cons ained Applica ion P o ocol (CoAP) . . . . . . . 8
2.1.1.2. Ex ensible Au hen ica ion P o ocol (EAP) . . . . . . 9
2.2. T us ed Execu ion En i onmen (TEE) . . . . . . . . . . . . . . . . . . 10
2.3. Aplicación de polí icas de compo amien o en disposi i os IoT . . . . . 12
2.3.1. Manu ac u e Usage Desc ip ion (MUD) . . . . . . . . . . . . . 13
2.3.1.1. De inición de un iche o MUD . . . . . . . . . . . . . 13
2.3.1.2. Di usión de un iche o MUD . . . . . . . . . . . . . . 13
2.3.1.3. Es uc u a de un iche o MUD . . . . . . . . . . . . . 14
2.3.1.4. Limi aciones de los iche os MUD . . . . . . . . . . . 15
3. Análisis de obje i os y me odología 17
4. Diseño y esolución del abajo ealizado 19
4.1. P oceso de boo s apping CoAP-EAP ................... 20
4.1.1. P ueba de una implemen ación del se ido de boo s apping . . 20
4.1.1.1. Con igu ación de una Raspbe y Pi 4 Model B . . . . 22
4.1.2. Ac ualización del se ido de boo s apping p opo cionado . . . 22
4.2. Secu ización de un disposi i o IoT . . . . . . . . . . . . . . . . . . . . 24
4.2.1. P ueba del p oceso de boo s apping con un clien e segu o . . . 29
4.3. In aes uc u a pa a aplica polí icas de compo amien o . . . . . . . . 30
4.3.1. Despliegue de un ERA en un disposi i o IoT . . . . . . . . . . . 30
4.3.1.1. P ueba del ERA . . . . . . . . . . . . . . . . . . . . . 32
4.3.2. Despliegue de in aes uc u a pa a abaja con iche os MUD . 32
4.3.2.1. Ac ualización del Boo s apping-Se e ......... 33
4.3.2.2. Despliegue de un se ido que p opo cione iche os MUD 34
4.3.2.3. Despliegue de un se ido que solici e iche os MUD . 35
4.3.2.4. De inición de un iche o MUD . . . . . . . . . . . . . 35
4.3.2.5. Coo dinación de la aplicación de polí icas . . . . . . . 37
4.4. P ueba de la PoC desa ollada . . . . . . . . . . . . . . . . . . . . . . . 40
5. E aluación de la PoC desa ollada 53
x iii Índice gene al
6. Conclusiones y ías u u as 57
Bibliog a ía 60
A. Anexo I. Fiche o MUD gene ado 64
B. Anexo II. T aducción del iche o MUD a MSPL 67
C. Anexo III. Base de da os del De ice and Domain Manage 69
D. Anexo IV. Con igu a SSH en una Raspbe y Pi 3 Model B 71
Índice de igu as
1. Escena io IoT p opues o . . . . . . . . . . . . . . . . . . . . . . . ii
2. P oposed IoT scena io ......................... x
2.1. In e acción pa a el p oceso de boo s apping ............. 8
2.2. Es uc u a de un TEE . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. P oceso de ob ención de un iche o MUD . . . . . . . . . . . . . . 14
4.1. Escena io IoT a desplega . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. PoC: A anque de las en idades dis in as al disposi i o IoT . . . . 41
4.3. PoC: Inicio del boo s apping ..................... 42
4.4. PoC: Consecuencias del boo s apping ................ 43
4.5. PoC: Consecuencias del boo s apping (con inuación) . . . . . . . . 44
4.6. PoC: Consecuencias del boo s apping en el con olado cen al . . 46
4.7. PoC: Consecuencias del boo s apping en el AAA se e . . . . . . 47
4.8. PoC: Consecuencias del boo s apping en el Pos -Se e . . . . . . 48
4.9. PoC: Consecuencias del boo s apping en el DDM . . . . . . . . . . 49
4.10. PoC: Consecuencias del boo s apping en el MUD Se e . . . . . . 49
4.11. PoC: Consecuencias del boo s apping en el MUD Manage . . . . 50
4.12. PoC: DDM as aplica el cambio de algo i mo de i ma . . . . . . 51
4.13. PoC: Raspbe y as aplica el cambio de algo i mo de i ma . . . 52
5.1. Flujo del escena io IoT desplegado . . . . . . . . . . . . . . . . . . 54
5.2. Tiempos de ejecución del boo s apping y del en o cemen en la PoC 54
5.3. Desglose de los iempos de ejecución del en o cemen en la PoC . . 55
C.1. PoC: Base de da os del DDM as comple a el boo s apping . . . 70
Índice de ablas
2.1. Limi aciones de un iche o MUD . . . . . . . . . . . . . . . . . . . . . 16
4.1. Lib e ías necesa ias pa a ejecu a el se ido de boo s apping . . . . . . 21
1. In oducción
El concep o de In e ne o Things (IoT) iene cada ez más p esencia en nues a so-
ciedad. Sin emba go, muchas eces es e é mino es u ilizado sin ene ealmen e cla o a
qué nos e e imos po IoT. Po ello, dado que se á el elemen o cen al de es e abajo,
es con enien e da una in oducción a es e concep o y mo i a po qué se ha decidido
es udia lo.
Es impo an e ene cla o que no exis e una de inición uni e sal pa a IoT [1, 2]. Es o
no quie e deci que no haya una o ma de desc ibi es e concep o, simplemen e cuando
se a a de explica qué es el IoT se ecu e a las ca ac e ís icas que se conside a que
es os ipos de disposi i os poseen. En es e abajo, pa a da es a de inición usa emos
las p opiedades que ema ca Ga cía Ca illo en [1]:
1. In e acción con el en o no. El IoT pe mi e mejo a el p oceso de ob ención de
in o mación median e el uso de máquinas. Es as son capaces de ealiza cie as
a eas de un modo más p eciso y e icien e que los se es humanos.
2. Conec i idad. El IoT pe mi e conec a a In e ne disposi i os con capacidades
muy di e sas, desde equipos complejos has a senso es con ecu sos muy limi ados.
Po an o, el concep o de IoT se puede esumi en que es á compues o po disposi-
i os de capacidades muy a iadas que son capaces de in e ac ua con el en o no en el
que es én desplegados y de conec a se a In e ne .
Es o p o oca que el abanico de mejo as ecnológicas a a és del uso de IoT se amplíe
eno memen e, eniendo como consecuencia un inc emen o muy no o io del núme o de
disposi i os IoT desplegados en odo el mundo. Es a endencia queda e lejada en [3]:
en 2023 se epo ó la exis encia de 16.6 billones de disposi i os, y en 2024 se espe aba
un c ecimien o has a los 18.8 billones. Además, se p onos icó el núme o de disposi i os
IoT desplegados en e 2024 y 2030, es imándose que, pa a inales del p esen e año,
2025, se engan 21.5 billones. Es os da os pe mi en e leja la g an ele ancia del IoT
en la sociedad ac ual.
Su impac o se ex iende a sec o es muy di e sos, como la ag icul u a, la indus ia, la
medicina o el come cio, ans o mando el día a día de las pe sonas median e soluciones
como las “Sma Homes”, “Sma Ci ies” o elojes in eligen es que pe mi en moni o i-
za la salud de las pe sonas.

2In oducción
Sin emba go, el IoT, además de sus g andes bene icios, ae consigo una se ie de
e os a los que se debe hace en e. En pa icula , des acan los elacionados con la
segu idad de los disposi i os, pues su capacidad pa a accede a In e ne iene como
consecuencia di ec a que es én expues os a amenazas que pueden comp ome e an o
su uncionamien o1como los da os2que ges ionan. Es a ca ac e ís ica jun o al hecho
de los disposi i os IoT es án masi amen e desplegados3po odo el mundo, p o oca
que la segu idad de los mismos sea un ema que debe se a ado con u gencia.
La p o ección que se debe p opo ciona a los disposi i os IoT no debe aba ca única-
men e los iesgos que se deban al acceso a In e ne . Es os disposi i os son desplegados
con la in ención de que abajen de o ma au ónoma, lo que puede p o oca que queden
expues os ísicamen e y, po an o, sean suscep ibles de su i a aques ísicos. En e es-
os, des aca el conocido como ampe ing, pues suele ene el mismo obje i o que un
a aque a a és de la ed: al e a el uncionamien o del disposi i o o oba in o mación
aliosa que maneje.
Po an o, encon a una solución que ga an ice la segu idad en cualquie ipo de
disposi i o IoT no es una a ea sencilla, pues la a iedad en e los disposi i os que se
pueden desplega hace que las medidas de segu idad se ean limi adas po las capaci-
dades de los disposi i os más es ingidos. Además, los disposi i os IoT se ca ac e izan
po ene un bajo cos e, po lo que es necesa io do a de segu idad a es os disposi i os
epe cu iendo lo menos posible en su p ecio.
También debe conside a se que los disposi i os IoT cuen an con ciclos de ida muy
la gos. Po ejemplo, un senso ag ícola diseñado pa a con ola la humedad del suelo
puede man ene se en uncionamien o du an e años. Es o p o oca que la p obabilidad
de que con el paso del iempo puedan i apa eciendo nue as amenazas que dejen ex-
pues os a los disposi i os, se inc emen e. Es necesa io diseña es os disposi i os pa a
que puedan se ac ualizados de un modo segu o y e icien e, e i ando que queden des-
p o egidos. De es e modo, los disposi i os IoT deben posee un sis ema de segu idad
que no solo los p o eja en el inicio de su ciclo de ida, sino que pueda se ac ualizado
mien as el disposi i o se man enga ac i o, asegu ando así su p o ección du an e oda
su ida ú il.
1El hecho de que un a acan e pueda al e a el compo amien o de un disposi i o IoT puede ene
consecuencias en odo el sis ema en el que es e ope a.
2P o ege la in o mación manejada po los disposi i os IoT es impo an e an o po in e eses pe so-
nales como po la egulación ac ual exis en e, la Ley O gánica de P o ección de Da os Pe sonales
y ga an ía de los de echos digi ales (LOPD) [4].
3Un allo de segu idad de ec ado en un disposi i o puede gene a p oblemas en un g an núme o.
3
La secu ización de los disposi i os IoT expues a e idencia la necesidad de es ablece
mecanismos de p o ección obus os y adap a i os desde el momen o del despliegue y
du an e oda la ida ú il de es os disposi i os. Ac ualmen e, la Uni e sidad de Mu -
cia, bajo el p oyec o aC i e sEcu i y oR connecTed de Ices liFecYcles (CERTIFY)
[5], es á desa ollando una p opues a que pe mi a ealiza una ges ión segu a de los
disposi i os IoT, asegu ando su co ec o uncionamien o.
En es e abajo se p esen a una P oo o Concep (PoC) que pe mi a pone a p ueba
cie os aspec os con los que se abaja en CERTIFY. En conc e o, la PoC se cen a en
el p oceso de boo s apping de un disposi i o IoT. Es e p oceso supone la ges ión de la
p ime a ase del ciclo de ida de un disposi i o, dic aminando qué debe ocu i cuando
un disposi i o es desplegado en un de e minado en o no y es a ancado po p ime a
ez. El obje i o del boo s apping es ealiza a eas de au en icación y au o ización que
asegu en que el disposi i o desplegado puede ope a en dicho en o no y iene limi adas
las acciones que puede ealiza sob e es e. Además, el boo s apping busca p epa a
al disposi i o pa a que pueda con inua con las siguien es e apas de su ciclo de i-
da: ope ación y man enimien o. Pa a ello, es a ase debe conclui con la ob ención, po
pa e del disposi i o, de ma e ial c ip og á ico que le pe mi a abaja de o ma segu a.
Dado que los ciclos de ida de los disposi i os IoT son muy la gos, es necesa io po-
de ealiza ac ualizaciones sob e es os, ya sean sob e sus compo amien os o sob e la
in o mación que poseen. La PoC ealizada ambién incluye una explo ación inicial del
uso de polí icas de compo amien o median e el es ánda Manu ac u e Usage Des-
c ip ion (MUD) [6], como mecanismo pa a ac ualiza o adap a la con igu ación de
los disposi i os una ez desplegados. En conc e o, es udia cómo de ini y aplica polí i-
cas de segu idad en los disposi i os IoT que han comple ado el p oceso de boo s apping.
Pa a el desa ollo de la PoC se ha hecho uso de dis in as ecnologías. El p oceso de
boo s apping sigue el modelo CoAP-EAP p opues o en [1], consiguiendo un p oceso
de au en icación lige o pa a el disposi i o IoT. Las cla es c ip og á icas y las ope-
aciones c í icas del mismo son p o egidas median e el uso de un T us ed Execu ion
En i onmen (TEE). Además, se implemen a un mecanismo pa a desplega polí icas
en el disposi i o IoT haciendo uso del es ánda MUD.
En esumen, es e abajo p opone un escena io de ges ión básica del ciclo de ida de
disposi i os IoT, basado en el p oyec o CERTIFY y con oco en el p oceso de boo s-
apping. A pesa de sus limi aciones, ep esen a un p ime paso hacia la in eg ación
de los componen es cla e del p oyec o y p opo ciona una base sob e la cual desa olla
u u as mejo as.
4In oducción
Finalmen e, p esen amos la o ganización que sigue es e documen o pa a expone el
abajo ealizado. La sección 2o ece una isión eó ica de las di e en es ecnologías,
elemen os y p o ocolos que han sido u ilizados en es e abajo. T as es o, en la sección
3se p esen a de o ma es uc u ada el obje i o de la PoC y cómo se ha abajado
pa a desplega la. En la sección 4se expone con de alle cada uno de los pasos seguidos
pa a c ea el escena io IoT que se p opone en es e abajo, así como los p oblemas
encon ados du an e su desa ollo y una p ueba de la PoC desplegada. La sección
5p esen a una e aluación de los iempos de ejecución de las p incipales ac i idades
que se ealizan en el escena io desplegado. Po úl imo, en la sección 6se discu en los
esul ados ob enidos con la PoC, exponiendo el abajo u u o que se puede desa olla
a pa i de es e escena io IoT.
2. Es ado del a e
A lo la go de es a sección se expond án los concep os eó icos de las he amien as y
ecnologías u ilizadas en es e abajo. El obje i o de hace es o es a a de p opo cio-
na un en endimien o gene al de los di e en es elemen os u ilizados y a a de mo i a
su uso.
En conc e o, comenza emos dando una in oducción al p oceso de boo s apping.
Una ez conocido qué es es e p oceso, p esen a emos el modelo elegido, CoAP-EAP,
de iniendo así su uncionamien o y los p o ocolos sob e los que se basa. T as es o,
a a emos el concep o de los TEE, mo i ando así po qué es os son de g an u ilidad
pa a p o ege disposi i os IoT. Finalmen e, habla emos del es ánda MUD, concep o
cla e pa a pode con ola el compo amien o de los disposi i os IoT.
2.1. Boo s apping de disposi i os IoT
Tal y como menciona Ga cía Ca illo en [1], el ciclo de ida de un disposi i o IoT se
di ide en 3 ases: boo s apping, ope ación y man enimien o. La p ime a de es as e apas
supone el a anque y con igu ación inicial del disposi i o pa a pe mi i que se una de
o ma segu a a la ed IoT donde el disposi i o p e ende abaja . T as es a, comienza la
ase de ope ación, donde el disposi i o ealiza las a eas pa a las que ha sido diseñado.
Cada cie o iempo, el disposi i o eque i á en a en la ase de man enimien o pa a
ecibi ac ualizaciones que man engan su co ec o uncionamien o.
En es a sección nos cen amos en la p ime a de es as ases, el boo s apping. Es a
e apa iene luga cuando, as su ab icación, el disposi i o es desplegado en el en o no
en el que abaja á. Como ya se ha comen ado, un disposi i o no debe pode empeza a
abaja con o me es desplegado, pues es o supond ía una se ie de iesgos an o pa a el
disposi i o como pa a el p opio en o no donde es á ope ando. Po es e mo i o, apa ece
el concep o de boo s apping. Es e p oceso busca lle a a cabo dos ac i idades pa a
conside a al disposi i o como segu o y pe mi i que comience con sus ope aciones
[1, 7]. Es as son:
•Au en icación y au o ización del disposi i o. Se debe comp oba quién es
el disposi i o y qué pe misos iene pa a ealiza acciones den o del en o no.
12 Es ado del a e
donde se ejecu an las aplicaciones no males y enemos el uncionamien o habi ual del
disposi i o. Cabe des aca que, pa a pe mi i la in e acción en e ambos mundos, es
necesa io hace uso de una API.
Es impo an e ene cla o qué p opiedades se pe siguen alcanza al u iliza TEEs
[20, 21]. Es as son:
•Aislamien o. Se debe c ea un en o no den o del disposi i o que es é aislado
de los p ocesos y aplicaciones no c í icas.
•Con idencialidad. Los da os de una TA no deben pode se ob enidos po
ninguna o a aplicación.
•In eg idad. Las TAs no deben pode se modi icadas.
•Ejecución segu a. Hay que e i a que nadie pueda desci a qué ocu e mien as
se ejecu a una TA.
•Acceso con olado. Cada TA debe pode accede únicamen e a sus p opios
ecu sos.
Concluimos es a sección con un ejemplo de uso de los TEEs: p o ege las cla es que
se u ilizan pa a ci a las comunicaciones. En muchas ocasiones, es as cla es es án de
o ma cla a en el código de nues as aplicaciones. Es o p o oca que, si alguien consigue
accede al código uen e, pueda ob ene las. A a és del uso de un TEE podemos
p o ege esas aplicaciones den o del en o no segu o. Así, uno de los usos más habi uales
de los TEEs es cuando se necesi a ealiza ope aciones c ip og á icas.
2.3. Aplicación de polí icas de compo amien o en
disposi i os IoT
Los disposi i os IoT son capaces de conec a se a In e ne , lo que les lle a de mane a
ine i able a es a expues os a amenazas. Po an o, un obje i o que debe se unda-
men al cuando se abaja con IoT es minimiza los iesgos a los que es án expues os.
En es e sen ido, el MUD [6], un es ánda de inido po el IETF, pe mi e de ini en un
iche o una se ie de polí icas que desc iban el compo amien o espe ado en un disposi i-
o. Es as polí icas pueden se u ilizadas pa a moni o iza compo amien os sospechosos
(como se p opone en [22]) o pa a educi la supe icie de a aque del disposi i o me-
dian e su aplicación (como se plan ea en es e abajo).
Po an o, el MUD pe mi e es anda iza la de inición de polí icas de compo amien-
os de disposi i os IoT. Los iche os que con ienen dichas polí icas son llamadados

2.3. Aplicación de polí icas de compo amien o en disposi i os IoT 13
iche os MUD y el p opio es ánda MUD es ablece una a qui ec u a pa a desplega y
ob ene es os iche os.
Pa a comp ende mejo el concep o de un iche o MUD ecu imos al ejemplo p esen-
ado en [6]: “Una bombilla iene como obje i o ilumina una habi ación, pe o, además,
pod ía se diseñada pa a pe mi i que sea con olada de o ma emo a a a és de la
ed. Cualquie acceso a la ed po pa e de la bombilla que no enga es e p opósi o
supone una comunicación no deseada. Así, la bombilla no debe comunica se con nin-
gún se icio ni disposi i o que no es é elacionado con es a uncionalidad. Teniendo
es o cla o, podemos es ablece que la bombilla solo debe pode accede a In e ne pa a
conec a se al se icio que la con ola de o ma emo a”. Es e ipo de compo amien os
son los que se busca con ola al de ini un iche o MUD: se es udia el ipo de dis-
posi i o y se es ingen sus comunicaciones a a és de la ed pa a do a lo de mayo
segu idad en e a a aques.
2.3.1. Manu ac u e Usage Desc ip ion (MUD)
Los iche os MUD de inen las conduc as pe mi idas en un disposi i o IoT. Po ello,
pa a pode abaja con ellos es con enien e conoce quién se enca ga de de ini los,
cómo se di unden, cuál es la es uc u a que deben ene y qué limi aciones p esen an.
Las espues as a es as cues iones se abo dan en las siguien es secciones.
2.3.1.1. De inición de un iche o MUD
La en idad enca gada de de ini las polí icas de compo amien o espe adas en un
de e minado disposi i o IoT se llama, según [6], manu ac u e . Es e é mino se usa con
cie a ambigüedad, ya que no malmen e hace e e encia al ab ican e del disposi i o.
Sin emba go, en el con ex o de los iche os MUD, su signi icado puede a ia en unción
del disposi i o IoT conc e o. En el es ánda ci ado, se expone que, aunque el é mino
manu ac u e puede esul a ago, hace e e encia a una en idad den o de la cadena
de suminis o del disposi i o que se enca ga de de ini un iche o MUD pa a desc ibi
su p opósi o de uso.
2.3.1.2. Di usión de un iche o MUD
Una ez que el manu ac u e gene a un iche o MUD, es e debe pode se consul ado.
El p oceso pa a pode ob ene el con enido de un iche o MUD es el siguien e:
1. El disposi i o IoT es capaz de p opo ciona la ubicación del iche o MUD a
a és de una Uni o m Resou ce Loca o (URL) a la que se llama MUD URL.
Es a in o mación se compa e du an e el p oceso de boo s apping.
14 Es ado del a e
2. Debe exis i una en idad, denominada MUD Manage , que sea capaz de ecibi
un MUD URL y a pa i de es e gene a una pe ición pa a ob ene el iche o
MUD.
3. Los iche os MUD son almacenados en en idades llamadas MUD Se e . Cuando
un MUD Manage hace una pe ición de un iche o MUD a a és de su MUD
URL, el MUD Se e es el enca gado de esponde con el iche o MUD pe inen e.
De es e modo, una ez se iene el iche o MUD, se puede in e p e a su con enido
pa a aplica las polí icas de compo amien o de inidas en es e.
Figu a 2.3: P oceso de ob ención de un iche o MUD
La igu a 2.3 mues a un esquema esumen de cómo se ob iene un iche o MUD4.
Es impo an e señala que un iche o MUD puede se modi icado con el paso del
iempo, po lo que el MUD Manage debe es a p epa ado pa a ene es o en cuen a y
ac ua en consecuencia.
2.3.1.3. Es uc u a de un iche o MUD
La es uc u a de un iche o MUD es á ampliamen e de allada en [6]. Po ello, en es a
sección se des aca án solo los aspec os que se conside an más ele an es.
La es uc u a de un iche o MUD es á de inida a a és de un modelo Ye Ano he
Nex Gene a ion (YANG) [23]. Además, pa a su ansmisión po la ed se usa se iali-
zación Ja asc ip Objec No a ion (JSON) [24]. Su con enido se con o ma a a és de
los siguien es elemen os:
•ie -mud [6]: Con iene in o mación ele an e pa a comp oba la alidez del p o-
pio iche o MUD, además de una e e encia a las Access Con ol Lis s (ACLs)5
[25] que se de inen en el iche o, indicando su nomb e y el sen ido de la comuni-
cación en el que se aplican (hacia/desde el disposi i o).
4Imagen basada en [22].
5Una ACL cons i uye una polí ica de ed que puede aplica se sob e un disposi i o.
2.3. Aplicación de polí icas de compo amien o en disposi i os IoT 15
•ie -access-con ol-lis [25]: Pe mi e de ini las eglas que con o man las di e-
en es ACLs que se quie en aplica .
•ie -acldns [6]: Pe mi e u iliza nomb es de dominio en eglas que se de inan
sob e una ACL.
Un iche o MUD álido con iene como con enedo es aíz a ie -mud e ie -access-
con ol-lis . Es in e esan e des aca que es posible hace uso de ex ensiones pa a pode
añadi con enedo es aíz, ampliando así la in o mación ansmi ida en un iche o MUD.
En el caso de que e u iliza ex ensiones es as deben se decla adas den o del con e-
nedo ie -mud usando el alo ex ensions.
2.3.1.4. Limi aciones de los iche os MUD
Respec o a los iche os MUD no solo es impo an e ene un modo es anda izado pa a
la de inición de polí icas de compo amien o de un disposi i o y la ob ención de iche os
de es e ipo; ambién es necesa io se capaces de aplica dichas polí icas. Además, es as
polí icas pueden cambia du an e el ciclo de ida del disposi i o, equi iendo po an-
o ac ualiza las. Es os aspec os no son incluidos en la de inición del es ánda MUD [26].
Exis en o os p oblemas asociados al uso del MUD al y como se expone en [22]:
Limi ación Desc ipción de la limi ación
Necesidad de un
p oceso de
aducción
Las polí icas que se de inen a a és de un iche o MUD no
pueden se di ec amen e aplicadas. Es necesa io ealiza un
p oceso de aducción del con enido del iche o pa a pode
p ocesa y aplica es as polí icas co ec amen e.
Fal a de
exp esi idad
Los iche os MUD ienen limi aciones pa a pode exp esa
polí icas que ayan más allá de la capa de ed.
Exis encia de
con lic os
Es habi ual que en los en o nos donde se despliegan
disposi i os IoT que hacen uso de iche os MUD, exis an ya
de inidas cie as polí icas de segu idad. En ocasiones, las
polí icas de inidas en el en o no del disposi i o IoT pueden
en a en con lic o con las que apa ecen indicadas en el iche o
MUD.
Tiempo de alidez
de un iche o MUD
En e el con enido de un iche o MUD, apa ece el iempo de
alidez de es e. Así, el MUD Manage no debe ía comp oba
ac ualizaciones de es e iche o an es de expi a dicho pe iodo.
Sin emba go, el abajo en In e ne implica cambios casi
cons an es, po lo que un iche o MUD pod ía se modi icado
an es de que se cumpla el iempo de alidez. De es e modo,
segui ielmen e el es ánda implica ía que pudie a da se el
caso de que el iche o MUD usado es é obsole o, po lo que
es a íamos aplicando polí icas inco ec as en el dispos i o.
16 Es ado del a e
Limi ación Desc ipción de la limi ación
Ac ualización de los
iche os MUD
El es ánda MUD de ine que el iche o MUD es ob enido
cuando el disposi i o IoT en ía el MUD URL al MUD
Manage . Sin emba go, no especi ica ningún modo de ob ene
el iche o MUD cuando haya ac ualizaciones de es e. Tampoco
de ine ningún mecanismo pa a que el manu ac u e del
disposi i o pueda a isa de cambios de es e iche o.
MUD Se e como
único pun o de allo
Si el se ido que p opo ciona un iche o MUD se e
comp ome ido, el sis ema se e ía en p oblemas, pues
pod íamos u iliza iche os MUD que no sean co ec os.
Tabla 2.1: Limi aciones de un iche o MUD
Cabe menciona que pa a algunos de los p oblemas mencionados ya se es án o e-
ciendo soluciones. Po ejemplo, en el caso pa icula de la al a de exp esi idad del
MUD, ac ualmen e exis e una p opues a pa a su ex ensión a a és del uso del len-
guaje Medium-le el Secu i y Policy Language (MSPL) [27, 28]. Dicha p opues a es á
desc i a en [29] y p opone amplia el con enido del MUD median e una ex ensión lla-
mada umu-mspl-lis :mspls. A a és de es a se pueden inclui polí icas de segu idad
más complejas y que no es én en ocadas únicamen e en la capa de ed. Es impo an e
ene en cuen a que la p opues a mencionada equie e in oduci un paso in e medio
pa a pode aplica las polí icas que se incluyan en el MUD, es as deben se p e iamen e
aducidas a lenguaje MSPL pa a pode in e p e a las y así aplica las. Es a ex ensión
es u ilizada en es e abajo, en conc e o, en el iche o MUD que se de ine en la sección
4.3.2.4 se explica cómo ha sido u ilizada.
3. Análisis de obje i os y me odología
El obje i o de es e abajo es desa olla una PoC del p oyec o CERTIFY que es á
siendo desa ollado en la Uni e sidad de Mu cia. En conc e o, se busca ob ene un
escena io simpli icado que pe mi a ealiza una ges ión segu a del ciclo de ida de dis-
posi i os IoT. Pa a ello, se p es a especial in e és a la ase de boo s apping y se abaja
de o ma básica con la aplicación de polí icas de compo amien o en disposi i os IoT.
Po an o, la ges ión de las ases de ope ación y man enimien o del disposi i o se a a
como aspec o secunda io.
De es e modo, el abajo se di ide en es bloques:
1. P oceso de boo s apping. Se ha buscado log a una implemen ación un-
cional del modelo de boo s apping p opues o en la Uni e sidad de Mu cia po
Ga cía Ca illo en [1]. En conc e o, la implemen ación u ilizada es la que es á
ac ualmen e acep ada po el IETF [8].
2. Secu ización del disposi i o IoT. Pa a do a de la mayo segu idad posible
a los disposi i os, se ha es udiado el despliegue de un TEE que pe mi a p o ege
las ope aciones c í icas del disposi i o. Po ejemplo, las ope aciones c ip og á icas
du an e el p oceso de boo s apping.
3. E apas de ope ación y man enimien o. Aunque la ges ión de es as e apas no
es cubie a en su o alidad, se han desa ollado mecanismos que pe mi an ac ua
sob e disposi i os que hayan comple ado la e apa de boo s apping. En conc e o,
se ha ealizado un despliegue que pe mi a aplica polí icas de compo amien o
que es én de inidas en iche os MUD.
Respec o a la me odología de abajo seguida, es a no consis e en una in es igación,
sino en una PoC. De es e modo, pa a la p ueba del escena io desplegado se ha hecho
uso de una Raspbe y Pi 3 Model B y una Raspbe y Pi 4 Model B como disposi i os
IoT. Pa a la pues a en ma cha de las en idades que no co esponden al disposi i o IoT,
se ha u ilizado un o denado po á il de p opósi o gene al.
El abajo desa ollado pa a c ea el escena io IoT que se p esen a en es e abajo
se puede esumi en las siguien es e apas:
1. Despliegue y p ueba de un se ido que pe mi a ealiza el boo s apping siguiendo
el modelo CoAP-EAP.

18 Análisis de obje i os y me odología
2. Despliegue de un TEE en una Raspbe y Pi 3 Model B.
3. P ueba del p oceso de boo s apping en e el se ido desplegado en la e apa 1 y
el disposi i o IoT con igu ado en la e apa 2.
4. Despliegue y p ueba de un p oceso que pe mi a aplica polí icas de compo -
amien o en una Raspbe y Pi 3 Model B que haya comple ado el p oceso de
boo s apping. Siguiendo la e minología del p oyec o CERTIFY a dicho p oceso
se le llama En o cemen and Recon igu a ion Agen (ERA).
5. Despliegue y p ueba de un se ido capaz de p opo ciona iche os MUD a pa i
de un MUD URL
6. Despliegue y p ueba de un se ido capaz de p ocesa MUD URLs, solici a los
iche os MUD asociados, y aduci las polí icas que con engan pa a aplica las
en un disposi i o IoT.
7. In eg ación de las e apas 4, 5 y 6 pa a aplica polí icas de compo amien o de i-
nidas en iche os MUD sob e disposi i os IoT.
8. P ueba del escena io comple o: unión de la e apa 3 y 7.
9. Documen ación del abajo ealizado.
4. Diseño y esolución del abajo
ealizado
En es a sección se p esen a el abajo ealizado pa a cons ui la PoC basada en el
p oyec o CERTIFY [5]. Pa a ello, u ilizando como base código que pe enece a dicho
p oyec o, se discu e cómo ha sido u ilizado, modi icado cuando ha sido necesa io, y
es eado pa a pode in eg a lo en un escena io que cumpla con los obje i os de inidos
en la sección 3.
En conc e o, se desc ibe cómo se ha ealizado el despliegue de un p oceso de boo s-
apping que siga el modelo CoAP-EAP. T as es o, se de ine cómo ealiza el despligue
de un TEE que pe mi a p o ege las ope aciones c í icas de una Raspbe y Pi 3 Model
B. Finalmen e, se p esen a el abajo desa ollado pa a de ini y dis ibui un iche o
MUD que pueda se u ilizado pa a aplica polí icas de compo amien o en un dispo-
si i o IoT que haya comple ado el p oceso de boo s apping. Además, pa a que es as
polí icas puedan se aplicadas en el disposi i o, se explica cómo desplega un ERA en
una Raspbe y Pi 3 Model B. Una ez p esen adas odas las en idades que cons i uyen
el escena io IoT del abajo, se expone una p ueba del co ec o uncionamien o de la
PoC.
Figu a 4.1: Escena io IoT a desplega
20 Diseño y esolución del abajo ealizado
La igu a 4.1 mues a un esumen del escena io que se desa olla en es e abajo. A
lo la go de es a sección se i á desc ibiendo el papel de cada una de las en idades que
apa ecen en es e diag ama, así como el p oceso que se siguió pa a inco po a las en el
escena io.
4.1. P oceso de boo s apping CoAP-EAP
En es a e apa el obje i o e a desplega un se ido capaz de ealiza el p oceso de
boo s apping CoAP-EAP de inido en [8]. Pa a ello, se hizo uso de dos ma e iales:
1. Aunque el modelo CoAP-EAP es á de inido en el es ánda del IETF, se p opo -
cionó un diag ama del lujo espe ado du an e el p oceso de boo s apping. Es e
diag ama pe enece al p oyec o CERTIFY, cuyo obje i o es á expues o en [26].
Dado que es e p oyec o aún es á en desa ollo y su ma e ial no me pe enece,
es e diag ama no se incluye po cues iones de p i acidad.
2. Una e sión de un se ido que sigue el modelo CoAP-EAP, basada en la publi-
cada en [30].
De es e modo, dado que ya se disponía de un código comple amen e desa ollado pa-
a el se ido de boo s apping, el obje i o e a comp oba que es e e a uncional, pues,
aunque había sido p obado en simulaciones, no se había p obado con máquinas eales.
Pa a comp oba el co ec o uncionamien o de dicho se ido e a necesa io en ende
el modelo CoAP-EAP y el diag ama de lujo p opo cionado. Una ez hecho es o, se
debía comp oba que el código uen e del se ido seguía ambos modelos. Finalmen e,
se debía pone en ma cha el se ido y e que el in e cambio de mensajes pa a com-
ple a el boo s apping e a co ec o.
En es e pun o, es impo an e ene en cuen a que el código p opo cionado pe enece
a un p oyec o que aún es á i o, lo que p o ocó ene que abaja con a ias e siones
di e en es del se ido .
4.1.1. P ueba de una implemen ación del se ido de
boo s apping
T as ecibi la p ime a e sión del código, lo p ime o que se hizo, ue a a de pone -
la en ejecución, pa a que, independien emen e de que su implemen ación uese co ec a
o no, se comp obase que no había ningún e o de p og amación ocul o po el uso de
un en o no de simulación pa a su desa ollo.
4.1. P oceso de boo s apping CoAP-EAP 21
Dado que el código es aba desa ollado en C, e a necesa io compila lo. Pa a ello,
p e iamen e había que ins ala lib e ías que se habían usado pa a desa olla el código,
pues es as son muy especí icas y po lo gene al no suelen es a ins aladas. En conc e o,
la p ueba es aba siendo ealizada sob e un Ubun u 24.04, y con la ins alación gené ica,
las lib e ías que se u ie on que ins ala ue on:
Lib e ía Desc ipción
libcoap3-de Pe mi e abaja con CoAP.
libmic oh pd-de Pe mi e implemen a se ido es HTTP de o ma sencilla.
libssl-de Pe mi e abaja con OpenSSL [31], siendo es e ú il pa a
abaja con c ip og a ía.
uuid-de Pe mi e c ea Uni e sally Unique Iden i ie s (UUIDs) [32] de
o ma sencilla.
libcu l4-openssl-de
Pe mi e hace pe iciones a se ido es web de o ma segu a pa a
u iliza lo de mane a simila a como se usa la he amien a de
línea de comandos cu l.
libcjson-de Pe mi e abaja con da os en o ma o JSON.
Tabla 4.1: Lib e ías necesa ias pa a ejecu a el se ido de boo s apping
Una ez ins aladas odas las lib e ías necesa ias y compilando con la he amien a
gcc, se pudo pone en ejecución el se ido . Es a p ueba de ec ó un p oblema: había
un e o de p og amación que impedía la ejecución. El mo i o de es e e o e a que
se hacía una comp obación sob e el es ado de un socke de la comunicación an es de
inicializa lo, lo que p o ocaba la inalización p ema u a del código. Po an o, se solu-
cionó ese allo y se epo ó al desa ollado del código.
Una ez que el se ido es aba en uncionamien o, sin comp oba su implemen ación,
se decidió es ea si es e e a capaz de comunica se con o a en idad. Pa a hace es o,
se u ilizó un código de clien e (código que se debe ía ins ala en un disposi i o IoT) de
p ueba que ambién se había p opo cionado jun o al del se ido de boo s apping. Al
lanza ambas en idades, se localizó un nue o p oblema, pe o aho a en el clien e. Es e
hacía uso de la in e az de ed del disposi i o que ejecu ase ese código; sin emba go,
es e alo e a necesa io in oduci lo de o ma es á ica en el p og ama, lo que p o ocaba
que uese dependien e de la máquina en la que se ejecu ase.
T as soluciona es e p oblema y epo a lo, an o clien e como se ido e an capaces
de comunica se y, po los mensajes de debug que se mos aban, pa ecían ealiza un
p oceso de boo s apping. Sin emba go, aho a e a el u no de comp oba que el código
desa ollado e a co ec o y seguía el modelo CoAP-EAP.
An es de comenza con es a a ea se ecibió una nue a e sión del código, que había
co egido los e o es epo ados y algunos que aún no se habían descubie o. Po es e
mo i o, se abandonó es a e sión y se pasó a abaja con la nue a.
28 Diseño y esolución del abajo ealizado
que el make allase jus o en el úl imo comando, po lo que podemos ejecu a lo a mano
as ins ala las.
T as ealiza es e p oceso, en /op ee/ou / enemos la imagen SD que se necesi a pa a
la Raspbe y Pi 3 Model B. En conc e o, en es e di ec o io se debe busca el a chi o
pi3-sdca d.img y copia lo en la SD que se aya a usa pa a la Raspbe y. El siguien e
paso es explica cómo hace es o.
Lo p ime o que se debe hace es conec a la SD a nues o PC y acia su con enido
(si es que iene alguno):
lsblk # Vemos dónde se ha mon ado la SD en
# nues o sis ema
sudo umoun </RUTA1> # Desmon amos odos los pun os dónde se
... # haya mon ado la SD
sudo umoun </RUTAN>
sudo disk <NOMBRE_SD> # Accedemos a la SD con disk usando el
# nomb e ob enido con lsblk. El obje i o
# se á bo a odas las pa iciones que
# enga y c ea una nue a desde ce o. Es
# impo an e gua da los cambios an es
# de sali
sudo mk s. a -F 32 <PARTICIÓN_SD_CREADA> # Fo ma eamos la pa ición c eada en la SD
T as es o, se debe copia la imagen c eada en la SD:
# Copiamos la imagen c eada del con enedo a nues o PC
docke cp <CONTAINER_ID>:/op ee/ou / pi3-sdca d.img .
# Copiamos la imagen a la SD
sudo dd i = pi3-sdca d.img o =<NOMBRE_SD> bs=1024k con = sync s a us=p og ess
Po úl imo, an es de pasa a comp oba que el uncionamien o con el TEE c eado
pa a la Raspbe y es co ec o, se puede hace una comp obación ápida pa a e que el
con enido de la SD es el adecuado, pues en ocasiones la ope ación de copia de la imagen
puede alla , p o ocando que, si se a di ec amen e a la Raspbe y, no a anque. Es a
comp obación se puede hace del siguien e modo:
# Vemos las pa iciones que iene la imagen c eada (debe ían se 2)
sudo disk -l pi3-sdca d.img
# Comp obamos que nues a SD iene las mismas pa iciones
sudo disk -l <NOMBRE_SD>
# Pa a cada pa ición que enga la SD hacemos el siguien e p oceso (el obje i o es
# comp oba que iene la es uc u a de iche os espe ada):
sudo mkdi -p /mn /<RUTA-DESEADA-PARA-LA-PRUEBA>
sudo moun <PARTICIÓN-X-SD> /mn /<RUTA-DESEADA-PARA-LA-PRUEBA>
ls <PARTICIÓN-X-SD> /mn /<RUTA-DESEADA-PARA-LA-PRUEBA>
sudo umoun /mn /<RUTA-DESEADA-PARA-LA-PRUEBA>

4.2. Secu ización de un disposi i o IoT 29
T as comple a es e úl imo paso, se iene una SD lis a pa a usa en la Raspbe y con
el código necesa io pa a desplega un clien e segu o du an e el p oceso de boo s apping.
Po an o, se end ía desplegada la segunda en idad del escena io IoT de inido en la
igu a 4.1:Boo s apping Agen . Sin emba go, an es de da po hecho que es o es así,
se debe comp oba que el boo s apping se comple a de o ma exi osa. Es a es la a ea
que se debe hace an es de da po concluida es a sección.
4.2.1. P ueba del p oceso de boo s apping con un clien e segu o
La p ueba de que el TEE y el boo s apping uncionan co ec amen e es muy sencilla
g acias a que an o los desa ollado es de OP-TEE como el desa ollado del código
del clien e pa a el boo s apping han desa ollado es s. Así, ejecu ando es os es s y
iendo que son pasados con éxi o, se puede da po concluida la p ueba.
Una ez se a anca la Raspbe y, disponemos de una e minal en la que se pueden
ejecu a comandos. Pa a p oba los es s de los desa ollado es de OP-TEE bas a con
ejecu a el comando x es , mien as que pa a ejecu a los es elacionados con el
boo s apping, se debe ejecu a el comando secu i y_api_ es 2. Du an e la p ueba,
se ob u ie on los siguien es esul ados:
• Los es s c eados po los desa ollado es de OP-TEE ue on pasados con éxi o.
• Los es s elacionados con el boo s apping die on e o en su ejecución. Es o ue
epo ado al desa ollado del código y se consiguie on de ec a dos p oblemas:
1. Había un e o en el nomb e de una de las unciones del código.
Dos iche os enían una unción llamada main. Es o hacía que el pun o de
comienzo del p og ama en ase en con lic o en e es os iche os y se ompiese
el o den de ejecución, p o ocando la inalización p ema u a del p og ama.
2. El código del clien e e a incompa ible con el del se ido . En la
sección 4.1 habíamos hablado de que jun o al se ido se había u ilizado
un clien e de p ueba. Pa a el desa ollo del clien e secu izado se pensaba
que el código que se es aba ins alando en la Raspbe y e a el mismo que el
p obado en aquel momen o, pe o modi icado pa a hace uso del TEE. Sin
emba go, la ealidad es aba muy alejada de es o. Pa a encon a el o igen
del p oblema hubo que pone se en con ac o con los desa ollado es de ambos
códigos. T as habla con ellos, se iden i icó el p oblema. El se ido había
sido desa ollado siguiendo el modelo CoAP-EAP; sin emba go, no había
sido posible log a el uso de CoAP con OP-TEE, po lo que el desa ollado
del clien e secu izado op ó po anspo a los mensajes EAP di ec amen e
2Pa a que es e es uncione es necesa io que el se ido de la sección 4.1 es é en uncionamien o y
que la Raspbe y es é conec ada a In e ne . La o ma más cómoda de hace es o úl imo es u iliza
E he ne .
30 Diseño y esolución del abajo ealizado
sob e TCP. Es o p o ocaba que el clien e secu izado uese o almen e dis-
in o del p obado al desplega el se ido de boo s apping. Además, al usa
clien e y se ido p o ocolos de anspo e dis in os (se ido UDP, clien e
TCP), la comunicación en e ellos no e a posible. Se plan ea on en onces
dos posibles soluciones:
a) Desa olla un p oxy que hiciese de aduc o en e clien e y se ido .
b) Ac ualiza el se ido pa a abaja di ec amen e con EAP sob e TCP.
Cualquie a de las soluciones elegidas no e a idónea, pues se desca aba el
uso de CoAP y UDP, el cual es un aspec o cla e pa a segui el modelo
CoAP-EAP. Sin emba go, dadas las limi aciones de iempo pa a comple a
el abajo y la di icul ad que suponía abaja con OP-TEE, hubo que asu-
mi es a limi ación en el escena io. Finalmen e, la solución elegida ue la
segunda.
De es e modo, as encon a los p oblemas mencionados y pone les solución, se
ob u o una e ce a e sión del se ido de boo s apping. Además, hubo que egene a
la imagen de la SD pa a ac ualiza el código del clien e (es o solo equi ió ac ualiza
el código de Gi Hub y ol e a hace el make). T as es o, se epi ió la p ueba con las
nue as e siones de clien e y se ido y odos los es s ue on pasados exi osamen e,
comple ando así con el abajo en el Boo s apping Agen de la igu a 4.1.
4.3. In aes uc u a pa a aplica polí icas de
compo amien o
Una ez desplegado el modelo CoAP-EAP pa a ealiza el p oceso de boo s apping
en un disposi i o IoT, el paso inal pa a comple a la PoC p opues a en es e abajo,
es ealiza una ap oximación a la ges ión del disposi i o as a anza a la siguien e
ase de su ciclo de ida: ope ación. En es a sección, se explica el p oceso seguido pa a
desplega la in aes uc u a necesa ia que pe mi a aplica polí icas de segu idad sob e
un de e minado disposi i o IoT.
4.3.1. Despliegue de un ERA en un disposi i o IoT
T as desplega un disposi i o IoT capaz de ealiza el boo s apping, la siguien e a-
ea es con igu a lo pa a que sea capaz de ecibi ó denes de en idades ex e nas que
pe mi an an o ajus a sus polí icas de compo amien o como ejecu a acciones sob e
el mismo.
La en idad desplegada pa a pode hace es o, siguiendo la e minología del p oyec o
CERTIFY, es llamada En o cemen and Recon igu a ion Agen (ERA). Además, se ha
4.3. In aes uc u a pa a aplica polí icas de compo amien o 31
eu ilizado la implemen ación desa ollada en dicho p oyec o pa a es e abajo.
Pa a desplega el ERA en la Raspbe y hay que ene en cuen a que se debe modi-
ica el código del que dispone el sis ema OP-TEE. Po an o, es necesa io egene a
la imagen SD que se u iliza. En conc e o, se usó una nue a e sión de [37]. Además, el
ERA diseñado pa a el p oyec o CERTIFY es aba desa ollado en Py hon, po lo que
se debía ins ala Py hon en la Raspbe y. Es e paso ue bas an e complejo de ealiza ,
pues no se encon ó ninguna uen e que diese di ec ices sob e cómo añadi Py hon en
una Raspbe y Pi 3 Model B que haga uso de OP-TEE. Po es e mo i o, se conside a
con enien e p opo ciona una guía sob e cómo ealiza la ins alación de Py hon.
Cuando se desplegó OP-TEE en la sección 4.2 se c eó en el con enedo Docke el
di ec o io /op ee. En es e se dispone de una es uc u a de di ec o ios que pe mi e hace
la cons ucción del sis ema a a és de la he amien a make. Pa a hace es o, den o
de los di e en es di ec o ios se encuen an iche os Make ile que se an llamando en e
sí pa a acaba o mando la imagen de la SD. Po an o, pa a añadi Py hon al sis ema
es necesa io encon a el iche o exac o en el que se debe indica que se haga es o. T as
es udia el con enido de los di e en es iche os Make ile, se llegó a la conclusión de que
la cla e es aba en los di ec o ios /op ee/build oo y /op ee/ou -b .
En /op ee/ou -b hay un iche o ocul o, .con ig, en el que se debe indica que se
quie e añadi Py hon al sis ema. Pa a modi ica es e a chi o, no es con enien e hace lo
a mano, pues es o puede se complejo y acaba con e o es. En su luga , se puede hace
uso de una in e az g á ica accesible a a és de /op ee/build oo . Así, el p oceso que
se debe segui pa a ins ala Py hon (asumiendo que se abaja den o del Docke ) es
el siguien e:
# Accedemos a la in e az g á ica a a és de /op ee/build oo e indicamos con la opción "O"
# que la con igu ación seleccionada y los iche os gene ados se gua den en
# /op ee/ou -b . De es e modo ac ualizamos el iche o .con ig de /op ee/ou -b
cd /op ee/build oo
make O=/op ee/ou -b menucon ig
# Den o de la in e az g á ica seleccionamos lo siguien e:
"Ta ge packages" >> "In e p e e languages and sc ip ing" >> "[*] py hon3"
# Gua damos los cambios y nos salimos de dicha in e az
# Compilamos la con igu ación elegida pa a ac ualiza .con ig de /op ee/ou -b
make O=/op ee/ou -b
Una ez con igu ado Py hon, pa a e mina con el despliegue del ERA, se debe
ac ualiza el código con el que cuen a la Raspbe y. En conc e o, hay que ac ualiza el
código p oceden e de [37]3y añadi los iche os Py hon p opo cionados pa a desplega
el ERA en /op ee/ou -b / a ge / oo . T as es o, se puede egene a la imagen pa a la
SD.
3Es e código es á en con inuo cambio po se pa e de CERTIFY.
32 Diseño y esolución del abajo ealizado
4.3.1.1. P ueba del ERA
Pa a p oba el uncionamien o del ERA, igual que ocu ió con el Boo s apping Agen
de la sección 4.2, el au o del ERA diseñó un es que comp ueba la co ec a uncio-
nalidad de es e. El es incluye ealiza el boo s apping y, una ez se comple a, el
disposi i o pasa a ejecu a el ERA. Pa a pode comunica se con es e, se p opo cionó
o o sc ip en Py hon en el que se de inen dos comandos de p ueba4:
1. Reinicia el disposi i o pa a pode ealiza un nue o boo s apping.
2. Cambia el algo i mo de i ma que u iliza el disposi i o.
Median e la ejecución del es jun o a los comandos an e io es, se puede comp oba
la co ec a uncionalidad del ERA. Sin emba go, pa a comple a el despliegue de la
en idad En o cemen and Recon igu a ion Agen de la igu a 4.1 es necesa io que los
comandos lleguen de la en idad De ice and Domain Manage , de inida ambién en
dicha igu a. Po an o, el despliegue del ERA se pod á da po concluido una ez los
comandos lleguen de la en idad adecuada y se apliquen co ec amen e en el disposi i o.
Es o es lo que es udiamos en la siguien e sección del documen o.
4.3.2. Despliegue de in aes uc u a pa a abaja con iche os
MUD
Una ez enemos la Raspbe y Pi p epa ada pa a comple a un p oceso de boo s ap-
ping y ecibi comandos que egulen su compo amien o, es momen o de desa olla
las en idades necesa ias pa a gene a dichos comandos de o ma adecuada. Pa a hace
es o, nos basamos en el uso de iche os MUD, desplegando así la in aes uc u a nece-
sa ia pa a: p opo ciona iche os MUD; ecupe a iche os MUD a pa i de un MUD
URL; y con e i las polí icas de inidas en un iche o MUD a comandos comp ensibles
pa a el ERA desplegado. Des aca que, pa a las p uebas de dicha in aes uc u a, se
u iliza á un iche o MUD que es de inido desde ce o en es e abajo.
A la en idad cen al que ges iona á el abajo con los MUD se le llama á De ice
and Domain Manage (DDM), al y como se p opone en [38]. Además, pa a desplega
oda la uncionalidad mencionada se oma como pun o de pa ida código que ha sido
desa ollado pa a el p oyec o CERTIFY. Es impo an e ene en cuen a que es e p o-
yec o es ambicioso espec o al uso de los MUDs, cub iendo así aspec os que exceden el
obje i o de es e abajo. Po es e mo i o, el código eu ilizado cuen a con pa es que
no son ú iles en la PoC que se p opone en es e documen o, eniendo, po an o, que
de ec a las y elimina las.
4El ERA desplegado solo es capaz de ejecu a los dos comandos mencionados.
4.3. In aes uc u a pa a aplica polí icas de compo amien o 33
O o aspec o a des aca sob e el código del p oyec o CERTIFY es que es á desa olla-
do pa a in e ac ua con el disposi i o IoT no solo una ez que inaliza el boo s apping,
sino que ambién p e ende in e eni a mi ad de es e. El mo i o de hace es o es que las
polí icas de compo amien o se deben aplica en la con igu ación inicial del disposi i o
y no espe a a que es é ya uncionando. Sin emba go, ni el se ido de boo s apping
ni el ERA desplegados es án p epa ados pa a in e ac ua con la pa e de ges ión de
polí icas du an e el boo s apping. Es as en idades es án aún en desa ollo, po lo que
las di e en es pa es del p oyec o CERTIFY no es án pe ec amen e in eg adas en e
sí. El ERA desplegado se ac i a una ez comple ado el boo s apping, mien as que el
se ido de boo s apping simula la comunicación con la pa e de ges ión de polí icas5.
Así, la al a de in eg ación en e el ERA, el se ido de boo s apping y el código que
ges iona las polí icas, p o oca ene que hace modi caciones impo an es pa a pode
conec a odo el escena io.
4.3.2.1. Ac ualización del Boo s apping-Se e
Como ya hemos comen ado, con la e sión ac ual del se ido de boo s apping y del
ERA es imposible que la ges ión de polí icas se aplique ambién du an e el p oceso
de boo s apping. Po ello, po cues iones de iempo, se omó la decisión de que las
polí icas de compo amien o se aplicasen una ez comple ado el boo s apping.
Es a decisión buscaba no ene que modi ica el se ido de boo s apping. Sin emba -
go, hay un aspec o que debemos ene en cuen a: el en ío del MUD URL del disposi i o,
alo necesa io pa a pode ob ene el iche o MUD que gene a el manu ac u e . Es e
alo es en iado po el disposi i o al Boo s apping-Se e y es necesa io que se een íe
al DDM en el mismo momen o en que se ecibe. Es o pe mi e que, una ez comple a-
do el boo s apping, se sepa cómo ob ene el iche o MUD del disposi i o. Es e hecho
gene a cie as di icul ades, pues como ya hemos expues o, el se ido de boo s apping
no es á desa ollado pa a comunica se con el DDM, sino que simula la comunicación
en iando la in o mación del disposi i o a un se ido “ acío”. Si nos limi amos a cam-
bia dicho se ido po el DDM sin p eocupa nos de nada, se bloquea ía el p oceso de
boo s apping, pues el Boo s apping-Se e queda ía a la espe a de una espues a la
cual no es capaz de p ocesa .
Pa a sol en a es e p oblema, se buscó una solución in e media que a ec ase lo menos
posible a la es uc u a an o del DDM como del se ido de boo s apping. La solución
plan eada consis ió en modi ica el Boo s apping-Se e pa a que la in o mación que
mandaba al se ido “ acío” uese een iada au omá icamen e al DDM. Pa a e i a
5La simulación mencionada consis e en publica en un se ido de p ueba, da os del disposi i o IoT
que es á a ando de ealiza el boo s apping. Es e se ido de p ueba au omá icamen e esponde
con una espues a sin con enido ele an e, la cual es igno ada en el se ido de boo s apping y se
con inúa con el p oceso.

34 Diseño y esolución del abajo ealizado
que es e úl imo pudiese en ia un mensaje de espues a, se es ableció un imeou muy
bajo que ce ase la conexión an es de que el DDM pudiese gene a una espues a. De
es e modo, el se ido de boo s apping con inua ía su ejecución sin e se al e ado po
la uncionalidad del DDM. Es e cie e de conexión puede p o oca un e o en el DDM
si es e a a de aplica las polí icas en el disposi i o, pues el ERA no es á aún en uncio-
namien o. Po es e mo i o, se decidió implemen a una in e upción en la ejecución del
DDM pa a que el adminis ado del sis ema decidiese e oma la una ez comple ado
el boo s apping y e i a así el e o .
Como es e iden e es a solución supone ue es limi aciones en el uncionamien o del
escena io, pues solo pod emos ges iona un disposi i o IoT en cada momen o. Además,
la labo del DDM debe ía es a au oma izada pa a no depende de la supe isión de una
pe sona. Sin emba go, dadas las limi aciones p esen adas en el se ido de boo s apping
y en el ERA que se enían desplegados, es a e a la opción más iable pa a comple a
el escena io.
4.3.2.2. Despliegue de un se ido que p opo cione iche os MUD
Suponiendo que enemos iche os MUD álidos, haciendo uso de Py hon se ha des-
plegado un se ido HTTP que si a pe iciones GET pa a p opo ciona iche os MUD.
Es impo an e ene en cuen a que pa a que el se ido uese comple amen e uncional,
debe ía ene endpoin s con igu ados que co espondiesen a MUD URLs. Sin emba go,
debido a la na u aleza de es e p oyec o, nues o disposi i o no iene un MUD URL
asociado. En su luga , iene una cadena de p ueba que simboliza es e alo . Es po
ello, que el se ido es á con igu ado pa a esponde pe iciones a endpoin s del ipo
/mud/<de ice_id>, donde de ice_id es un iden i icado del disposi i o IoT del que se
quie e ob ene el iche o MUD asociado6. Si quisiésemos hace más ealis a es e escena-
io, pod íamos de ini pa a el disposi i o IoT de p ueba un MUD URL que u iese un
mayo sen ido, y con igu a en onces es e se ido pa a esponde únicamen e a dicho
endpoin . Des aca que, pa a es a p ueba, es e se ido p opo ciona á únicamen e un
iche o MUD, el de inido en la sección 4.3.2.4.
Así, con el despliegue de es a en idad enemos lis o el MUD Se e de inido en la
igu a 4.1.
6Es e alo es in e cambiado en e el disposi i o IoT, el se ido de boo s apping y el DDM, po lo
que podemos hace lo llega has a es e se ido .
4.3. In aes uc u a pa a aplica polí icas de compo amien o 35
4.3.2.3. Despliegue de un se ido que solici e iche os MUD
Una ez que enemos un se ido que es capaz de p opo ciona iche os MUD an e
pe iciones GET, necesi amos una en idad que sea la enca gada de hace le pe iciones.
Es a es la que llamamos MUD Manage en la igu a 4.1.
La implemen ación de es a en idad es á al amen e basada en la desa ollada pa a
el p oyec o CERTIFY, pe o ha sido simpli icada pa a ene lo es ic amen e necesa-
io pa a el despliegue de es e escena io. Así, median e Py hon se de ine un se ido
HTTP que, median e pe iciones GET, es capaz de ob ene un iche o MUD a pa i de
un MUD URL. Es e p oceso es iniciado cuando el MUD Manage ecibe un mensaje
POST al endpoin /mud. Dicho mensaje debe se en iado po el DDM y end á en su
con enido un MUD URL y el iden i icado del disposi i o IoT al que co esponde dicho
MUD URL. Es e iden i icado es lo que llamamos <de ice_id> en la sección 4.3.2.2.
Un aspec o a des aca sob e es a implemen ación es que, aunque el código se ha
dejado lis o pa a pode u iliza MUD URLs, cuando se a a hace la pe ición al MUD
Se e , independien emen e del MUD URL que se haya ecibido, siemp e se u iliza el
mismo endpoin : /mud/p ueba. Es o se hace así en p o de la simplicidad, pues como
ya hemos comen ado, los MUD URLs que se u ilizan son simples cadenas de ex o de
p ueba. Además, el MUD Se e iene un único MUD disponible. Po an o, pa a la
p ueba del co ec o uncionamien o, no es impo an e el endpoin que usemos pa a el
GET7.
4.3.2.4. De inición de un iche o MUD
El obje i o de oda la sección 4.3.2 es pode aplica polí icas de con igu ación en
nues a Raspbe y Pi una ez ha comple ado el p oceso de boo s apping. Pa a pode
hace es o necesi amos gene a un iche o MUD que sea compa ible con el ERA des-
plegado, es deci , el MUD debe con ene polí icas sopo adas po el ERA.
En nues o caso, se decidió op a po c ea un MUD que u iese la polí ica de cambio
de algo i mo de i ma8. Además, se comple ó el con enido de es e iche o con polí icas
de ed que de iniesen un MUD más comple o, aunque es as úl imas no uesen usadas.
En es a sección se expone cómo se ha ealizado la de inición del iche o MUD que
es u ilizado pa a la Raspbe y. Basándonos en [6] se c ea la es uc u a básica de un
iche o MUD que cumpla con el es ánda . Pa a ello, se hace uso de los con enedo es
ie -mud:mud e ie -access-con ol-lis s:acls. En es os se de ine el siguien e con enido:
7No obs an e, el código se ha dejado lis o pa a pode pasa a usa MUD URLs cuando se desee.
8Es a polí ica es una de los sopo adas po el ERA desplegado, al y como se desc ibe en la sección
4.3.1.1
36 Diseño y esolución del abajo ealizado
•ie -mud:mud. Los p incipales aspec os que se incluyen en es e bloque son la de-
inición del nomb e de las ACLs que apa ecen en el con enedo ie -ccess-con ol-
lis s:acls y la decla ación de las ex ensiones que se u ilizan pa a amplia el es án-
da MUD.
•ie -access-con ol-lis s:acls. En es e bloque de inimos una polí ica de comu-
nicación pa a el disposi i o. Asumiendo que odo lo que no se especi ique median-
e ACLs se á conside ado como á ico no pe mi ido, se es ablecen eglas pa a
es ingi la comunicación del disposi i o IoT únicamen e a conexiones con dis-
posi i os del en o no donde ha sido desplegado (se supond á que dicho en o no
es la ed 192.168.100.0/24). En pa icula , el disposi i o IoT solo pod á gene a
á ico hacia disposi i os de esa ed si u iliza Hype ex T ans e P o ocol Secu e
(HTTPS) [39], mien as que pod á ecibi á ico de cualquie ipo siemp e que
p o enga de es a ed.
Pa a e i a el p oblema de al a de exp esi idad del MUD mencionado en la sección
2.3.1.4, se hace uso de la ex ensión p opues a en [29]: umu-mspl-lis :mspls. De es e
modo, podemos exp esa polí icas más complejas que las que pe mi en de ini las ACLs.
En nues o caso, se hace uso de es a ex ensión pa a:
•De ini la polí ica de cambio de algo i mo de i ma en el disposi i o:
se debe pasa a usa Hash-based Message Au hen ica ion Code (HMAC) [40].
•Amplia la polí ica de ed de inida median e ACLs: se añade que o-
do el á ico que llegue al disposi i o desde un se ido de boo s apping de la
Uni e sidad de Mu cia sea pe mi ido.
El con enido del iche o MUD esul an e se puede e en el anexo A. Des aca que
la de inición del MUD ue una a ea bas an e compleja, pues es e debía se acep ado
po un aduc o diseñado pa a abaja jun o al DDM. La p oblemá ica es aba en
que el uncionamien o exac o de es e aduc o e a desconocido, pues la pe sona que
lo desa olló no es aba disponible. Po an o, hubo que desci a cómo uncionaba el
aduc o pa a c ea un MUD con sen ido y que a la ez uese acep ado po es e.
El iche o MUD de inido es el que p opo ciona el MUD Se e explicado en la sección
4.3.2.2. De es e modo, cuando se p ocese la polí ica de cambio de algo i mo de i ma,
es a se á en iada al ERA, mien as que el es o de las polí icas pod ían se en iadas
a en idades que ges ionen la ed donde abaja el disposi i o IoT, po ejemplo, a una
So wa e-De ined Ne wo king (SDN) [41], al y como se sugie e en [22].
Pa a conclui con es a sección, cabe menciona que el signi icado de odos los campos
u ilizados en los con enedo es ie -mud:mud, ie -access-con ol-lis :acls y umu-mspl-
lis :mspls puede se consul ado en [6], [25] y [29]. Po ello, pa a no hace demasiado
ex enso el documen o se e i a pone las de iniciones aquí.
4.3. In aes uc u a pa a aplica polí icas de compo amien o 37
4.3.2.5. Coo dinación de la aplicación de polí icas
Una ez enemos oda la in aes uc u a elacionada con la aplicación de polí icas
basada en iche os MUD es necesa io conec a odo el escena io. Es o se hace a a és
del De ice and Domain Manage p esen ado en la igu a 4.1. El DDM desplegado pa a
es e abajo iene las siguien es ca ac e ís icas:
1. Se comunica con el Boo s apping-Se e pa a ob ene in o mación sob e los dis-
posi i os que a an de ealiza el p oceso de boo s apping. Toda la in o mación
sob e es os disposi i os es almacenada en una base de da os ges ionada po el
DDM y cie a in o mación que se u iliza en esa base de da os se ob iene a a és
de es a comunicación, como la di ección IP o el MUD URL.
2. Solici a al MUD Manage los iche os MUD de los disposi i os IoT que es á
ges ionando. Pa a ello hace uso de los MUD URLs que a ob eniendo.
3. In e p e a el con enido de los iche os MUD que ob iene del MUD Manage y los
aduce a polí icas de compo amien o que puedan se u ilizadas. Es a aducción
se hace a lenguaje MSPL siguiendo el modelo suge ido en [29, 38].
4. In e p e a las polí icas ob enidas con la aducción pa a en ia comandos al ERA
cuando sea pe inen e.
Pa a desplega dicho DDM los pasos que se han ealizado pueden se esumidos del
siguien e modo:
•Paso 1. C eación de un en o no i ual pa a Py hon.
El código que ha sido eu ilizado del p oyec o CERTIFY pa a desplega el DDM
hace uso de lib e ías de Py hon muy especí icas. Po ello, pa a no ins ala en nues o
sis ema odas es as lib e ías, podemos c ea un en o no i ual que enga es ic amen e
lo necesa io pa a abaja con el DDM. Es o se puede hace del siguien e modo:
# Asumimos que es amos en el di ec o io donde enemos el código uen e del DDM
# C eamos un en o no i ual al que llamamos en . Si es e comando alla, p e iamen e
# hab á que ejecu a : sudo ap ins all py hon3.12- en
py hon3 -m en en
# Ac i amos el en o no i ual c eado
sou ce en /bin/ac i a e
# Una ez que enemos el en o no ac i ado, comenzamos a ins ala las lib e ías necesa ias
# den o de es e en o no
pip3 ins all pyangbind
pip3 ins all PyYAML
pip3 ins all SQLAlchemy
pip3 ins all Flask
pip3 ins all eques s
pip3 ins all bi a ay
44 Diseño y esolución del abajo ealizado
Figu a 4.5: PoC: Consecuencias del boo s apping (con inuación)

4.4. P ueba de la PoC desa ollada 45
Las igu as 4.4 y4.5 buscan mos a que el es ado de odas las en idades que apa-
ecían en la igu a 4.2 se ha is o ac ualizado. Sin emba go, a a de comp ende qué
ha ocu ido con es as imágenes se ía imposible, pues ni siquie a se puede e oda la
in o mación que han gene ado. Po ello, amos a mos a el es ado de cada una de
es as en idades po sepa ado.
Comenzamos en onces con las en idades elacionadas con el Boo s apping-Se e .
En conc e o, la igu a 4.2 mos aba que es e se di idía en dos en idades: BOOTS-
TRAPPING yAAA SERVER. Es as co esponden a las en idades que se de inie on
en la igu a 2.1, siendo BOOTSTRAPPING el con olado cen al y AAA SERVER
la in aes uc u a AAA.
La igu a 4.6 mues a la in o mación gene ada po la en idad BOOTSTRAPPING.
En ella, podemos con i ma que ac úa como el con olado cen al pa a ealiza el
boo s apping, pues es la en idad que ac úa como in e media io en e el disposi i o IoT
y el AAA SERVER. En la igu a apa ece un egis o sob e los p incipales e en os que
ocu en mien as se comple a el boo s apping. En e es os des aca la edi ección de
mensajes EAP en e el disposi i o IoT y el AAA SERVER, y el en ío de in o mación
hacia el De ice and Domain Manage una ez se ha comple ado la au en icación del
disposi i o. Es in e esan e des aca que en e la in o mación que se en ía al De ice and
Domain Manage se incluye el MUD URL que se debe ía usa pa a la con igu ación
de polí icas de segu idad en el disposi i o. Como se mencionó en la sección 4.3.2.2, la
URL que se puede obse a no iene un signi icado eal, es una cadena de p ueba que
pe mi e simula el uso de un MUD URL.
46 Diseño y esolución del abajo ealizado
Figu a 4.6: PoC: Consecuencias del boo s apping en el con olado cen al
4.4. P ueba de la PoC desa ollada 47
Figu a 4.7: PoC: Consecuencias del boo s apping en el AAA se e
48 Diseño y esolución del abajo ealizado
En la igu a 4.7 podemos e las acciones que se lle an a cabo en el AAA SERVER
du an e el p oceso de boo s apping. La igu a mues a con de alle la au en icación
EAP-PSK desc i a en la sección 2.1.1.2. Pa a indica el momen o en el que comienza
cada uno de los pasos desc i os en dicha sección se ha ema cado el mensaje que da
comienzo a cada e apa13. Además, es in e esan e des aca que al y como se expuso
en dicha sección el p oceso de au en icación EAP-PSK concluye con la ob ención de
ma e ial c ip og á ico. En la igu a podemos ap ecia es o al inal de la imagen, don-
de podemos e que se de i an dos cla es c ip og á icas de inidas pa a es e p o ocolo:
MSK y Ex ended Mas e Session Key (EMSK)
El siguien e paso es mos a cómo se ha is o ac ualizada la in o mación que mues a
el in e media io en e el Boo s apping-Se e y el De ice and Domain Manage , el
Pos -Se e . Es o se puede ap ecia en la igu a 4.8. En ella podemos e que ha
ecibido la in o mación del disposi i o que acaba de ealiza el boo s apping. En e
es a in o mación enemos la di ección IP del disposi i o IoT, un MUD URL y dos
iden i icado es del mismo.
Figu a 4.8: PoC: Consecuencias del boo s apping en el Pos -Se e
El hecho de que el Pos -Se e haya ecibido una ac ualización implica que es a
in o mación sea een iada al De ice and Domain Manage , p o ocando que se ecupe e
el iche o MUD asociado al disposi i o que ha ealizado el boo s apping. Po an o, las
en idades MUD Manage , MUD Se e y De ice and Domain Manage ac ualizan la
in o mación que mues an, indicando cómo se ecupe a el iche o MUD y se ealiza su
aducción a lenguaje MSPL. Es o se puede obse a en las igu as 4.9,4.11 y4.10.
13Des aca que el mensaje “AAA Se e : EAP-Response/Success message sen o clien ” ma cado en
la imagen es un e o del desa ollado del código. El mensaje que se es á en iado en ealidad es
el mensaje EAP PSK 3.
4.4. P ueba de la PoC desa ollada 49
Figu a 4.9: PoC: Consecuencias del boo s apping en el DDM
Figu a 4.10: PoC: Consecuencias del boo s apping en el MUD Se e

50 Diseño y esolución del abajo ealizado
Figu a 4.11: PoC: Consecuencias del boo s apping en el MUD Manage
Además, el De ice and Domain Manage egis a en su base de da os al disposi i o
que ha ealizado el p oceso de boo s apping. Es o se puede ap ecia en la igu a C.1
del anexo C14.
Una ez comple ado el p oceso de boo s apping, si ol emos a las igu as 4.3 y4.9,
podemos e que ambas han quedado lis as pa a ealiza un p oceso de econ igu ación
en el disposi i o IoT. En conc e o, podemos aplica la polí ica de cambio de algo i mo
de i ma. Es o es lo que se puede obse a en las igu as 4.12 y4.13.
14Es a o o ha sido añadida en el anexo Cpo al a de legibilidad en o ma o e ical.
4.4. P ueba de la PoC desa ollada 51
Figu a 4.12: PoC: DDM as aplica el cambio de algo i mo de i ma
52 Diseño y esolución del abajo ealizado
Figu a 4.13: PoC: Raspbe y as aplica el cambio de algo i mo de i ma
De es a o ma se pone in a la p ueba del escena io desplegado pa a es e abajo.
5. E aluación de la PoC desa ollada
En la sección 4hemos p esen ado la PoC desa ollada pa a es e abajo. En conc e o,
hemos ealizado es acciones: de ini los elemen os que la componen, explica cómo se
ha desplegado cada uno de esos elemen os y inalmen e, p opo ciona un ejemplo de
su co ec o uncionamien o.
En es a sección buscamos comple a la p esen ación de la PoC p opo cionando una
e aluación del sis ema desplegado. En conc e o, p opo ciona emos medidas del iempo
de ejecución de las p incipales ac i idades que se ealizan en el escena io p opues o.
De es e modo, es as pueden se i como base pa a u u as mejo as, pues las posibles
e oluciones de la PoC debe ían ene en e sus obje i os educi el iempo de ejecución
del escena io. Además, las medidas que se p esen a án en es a sección pueden se de
u ilidad pa a compa a cómo de buenas, en é minos de endimien o, son o as al e -
na i as pa a la ges ión de disposi i os IoT.
Pa a ealiza es a e aluación, el p ime paso es ene cla o el escena io que se ha
desa ollado en es e abajo, pues solo así se puede alo a qué ac i idades me ecen
la pena se e aluadas. Pa a ello, en la igu a 5.1 se p opo ciona un diag ama de lujo
que esume la PoC desa ollada. Como se puede obse a en dicha igu a, el escena io
sigue un lujo secuencial, donde el p ime paso es ealiza el p oceso de boo s apping
CoAP-EAP. Esa e apa concluye con el en ío al DDM de in o mación del disposi i o
que ha comple ado el boo s apping (pasos 2 y 3 del diag ama), pe mi iendo así que
pueda comenza la ase de econ igu ación del disposi i o. Una ez el DDM iene la
in o mación del disposi i o que ha comple ado el boo s apping, puede p ocede a e-
cupe a el iche o MUD que iene asociado. Pa a ello, in e ac úa con el MUD Se e a
a és del MUD Manage (paso 4 del diag ama). Así, as ecibi el MUD ile (paso 5
del diag ama), puede p ocesa lo y manda una solici ud de econ igu ación al disposi-
i o IoT si lo conside a pe inen e (paso 6 del diag ama). Dicha solici ud es p ocesada
po el ERA del disposi i o y si se conside a álida, es aplicada (paso 7 del diag ama).
Bibliog a ía
[1] D. Ga cía Ca illo. A CoAP-based boo s apping se ice o la ge-scale In e ne -
o - hings ne wo ks. PhD hesis, Uni e sidad de Mu cia (UMU), Mu cia, 2018.
[2] Miguel Angel López Peña. De Ops Aplicado a Sis emas IoT: De inición e Im-
plemen ación de P ocesos Con inuos de Moni o ización y Re oalimen ación.
PhD Thesis, Uni e sidad Poli écnica de Mad id, Mad id, 2021. URL h p:
//oa.upm.es/68043/.
[3] Sa yaji Sinha. IOT ANALYTICS, 2024. URL h ps://io -analy ics.com/
numbe -connec ed-io -de ices/.
[4] Ley O gánica 3/2018, de 5 de diciemb e, de P o ección de Da os Pe sonales y
ga an ía de los de echos digi ales., 2018. URL h ps://www.boe.es/eli/es/lo/
2018/12/05/3/con.
[5] CERTIFY, (s. .). URL h ps://ce i y-p ojec .eu/.
[6] Elio Lea , Ralph D oms, and Dan Romascanu. Manu ac u e Usage Desc ip ion
Speci ica ion, 2019. URL h ps://da a acke .ie .o g/doc/h ml/ c8520.
[7] Sameh Khal aoui. Secu i y boo s apping o In e ne o Things. PhD hesis,
Ins i u Poy echnique de Pa is, F ancia, 2022.
[8] Dan Ga cía Ca illo. EAP-based Au hen ica ion Se ice o
CoAP, 2024. URL h ps://da a acke .ie .o g/doc/h ml/
d a -ie -ace-wg-coap-eap-12.
[9] Russ Housley and D . Be na d D. Aboba. Guidance o Au hen ica ion, Au ho-
iza ion, and Accoun ing (AAA) Key Managemen , 2007. URL h ps://
da a acke .ie .o g/doc/h ml/ c4962.
[10] D . Be na d D. Aboba and Jona han Wood. Au hen ica ion, Au ho iza ion and
Accoun ing (AAA) T anspo P o ile, 2003. URL h ps://da a acke .ie .
o g/doc/h ml/ c3539.
[11] John Vollb ech , James D. Ca lson, La y Blunk, Be na d D. Aboba, and Hen ik
Le kowe z. Ex ensible Au hen ica ion P o ocol (EAP), 2004. URL h ps://
da a acke .ie .o g/doc/h ml/ c3748.

Bibliog a ía 61
[12] Zach Shelby, Klaus Ha ke, and Ca s en Bo mann. The Cons ained Applica-
ion P o ocol (CoAP), 2014. URL h ps://da a acke .ie .o g/doc/h ml/
c7252.
[13] Agus ín Bassi. In oducción a CoAP, 2021. URL h ps://www.go oio .com/
pages/a icles/coap_in o/index.h ml#:~: ex =CoAP%20(Cons ained%
20Applica ion%20P o ocol)%20es,que%20puedan%20comunica se%20sob e%
20in e ne .
[14] Hen ik Nielsen, Je ey Mogul, La y M Masin e , Roy T. Fielding, Jim Ge ys,
Paul J. Leach, and Tim Be ne s-Lee. Hype ex T ans e P o ocol – HTTP/1.1,
1999. URL h ps://da a acke .ie .o g/doc/h ml/ c2616.
[15] Eddy Wesley. T ansmission Con ol P o ocol (TCP), 2022. URL h ps://
da a acke .ie .o g/doc/h ml/ c9293.
[16] Use Da ag am P o ocol, 1980. URL h ps://da a acke .ie .o g/doc/
h ml/ c768.
[17] Flo en Be sani and Hannes Tscho enig. The EAP-PSK P o ocol: A P e-Sha ed
Key Ex ensible Au hen ica ion P o ocol (EAP) Me hod, 2007. URL h ps://
da a acke .ie .o g/doc/h ml/ c4764.
[18] I ai Tu bahn. In oduc ion o T us ed Execu ion En i onmen s (TEEs), 2024.
URL h ps://www.dynamic.xyz/blog/ us ed-execu ion-en i onmen s.
[19] Wha is a T us ed Execu ion En i onmen (TEE)?, 2019.
URL h ps://www. us onic.com/ echnical-a icles/
wha -is-a- us ed-execu ion-en i onmen - ee/.
[20] Wha is a T us ed Applica ion?, 2024. URL h ps://licelus.com/insigh s/
wha -is-a- us ed-applica ion#:~: ex =A%20T us ed%20Applica ion%
20is%20a,%2C%20au hen ica ion%2C%20and%20secu e%20s o age.
[21] In oduc ion o T us ed Execu ion En i onmen s. Technical epo ,
2018. URL h ps://globalpla o m.o g/wp-con en /uploads/2018/
05/In oduc ion- o-T us ed-Execu ion-En i onmen -15May2018.pd .
[22] Jose L. He nandez-Ramos, Sa a N. Ma heu, Angelo Fe audo, Gianma co Bal-
dini, Jo ge Be nal Be nabe, Poonam Yada , An onio Ska me a, and Paolo Be-
lla is a. De ining he Beha io o IoT De ices Th ough he MUD S anda d:
Re iew, Challenges, and Resea ch Di ec ions. IEEE Access, 9:126265–126285,
2021. ISSN 2169-3536. doi: 10.1109/ACCESS.2021.3111477. URL h ps:
//ieeexplo e.ieee.o g/documen /9531614/.
62 Bibliog a ía
[23] Ma in Bjö klund. The YANG 1.1 Da a Modeling Language, 2016. URL h ps:
//da a acke .ie .o g/doc/h ml/ c7950.
[24] Tim B ay. The Ja aSc ip Objec No a ion (JSON) Da a In e change Fo ma ,
2017. URL h ps://da a acke .ie .o g/doc/h ml/ c8259.
[25] Mahesh Je hanandani, Sonal Aga wal, Lisa Huang, and Dana Blai . YANG
Da a Model o Ne wo k Access Con ol Lis s (ACLs), 2019. URL h ps:
//da a acke .ie .o g/doc/h ml/ c8519.
[26] S e ano Sebas io, Sa a Ma heu, An onio Ska me a, Ricca do O izio, Dimi is Ka-
as, Da ia Schumm, Bu kha d S ille , Rosella Omana Mancilla, F ancesca Giam-
paolo, Simon Tuck, Thomas Bocek, Vincenzo Cuomo, Roland A oui, S eede i
Beena, Robe o Na done, Alessand o Cila do, Dinesh Sha ma, Rohi Boha a, and
Ja ie Pa a-Domínguez. Cybe secu i y Managemen Th oughou he IoT Sys-
ems Li ecycle – The CERTIFY App oach. In Rashid Mehmood, Guille mo He -
nández, Isabel P aça, Ja oslaw Wika ek, Roussanka Loukano a, A sénio Mon ei o
Dos Reis, An onio Ska me a, and Eleono a Lomba di, edi o s, Dis ibu ed Compu-
ing and A i icial In elligence, Special Sessions I, 21s In e na ional Con e ence,
olume 1198, pages 281–290. Sp inge Na u e Swi ze land, Cham, 2025. ISBN
978-3-031-76458-5 978-3-031-76459-2. doi: 10.1007/978-3-031-76459-2_26. URL
h ps://link.sp inge .com/10.1007/978-3-031-76459-2_26. Se ies Ti le:
Lec u e No es in Ne wo ks and Sys ems.
[27] Ful io Valenza and An onio Lioy. Use -o ien ed Ne wo k Secu i y Policy Speci i-
ca ion.
[28] Alejand o Molina Za ca, Jo ge Be nal Be nabé, Jo di O íz, and An onio Ska me-
a. Policy-based De ini ion and Policy o O ches a ion FInal Repo . Tech-
nical epo , 2018. URL h ps://ec.eu opa.eu/ esea ch/pa icipan s/
documen s/downloadPublic?documen Ids=080166e5c03 6297&appId=PPGMS.
[29] Sa a N. Ma heu, Albe o Robles Enciso, Alejand o Molina Za ca, Dan Ga cía-
Ca illo, José Luis He nández-Ramos, Jo ge Be nal Be nabé, and An onio F. Ska -
me a. Secu i y A chi ec u e o De ining and En o cing Secu i y P o iles in
DLT/SDN-Based IoT Sys ems. 2020. URL h ps://www.mdpi.com/1424-8220/
20/7/1882.
[30] Dan Ga cía Ca illo. d a -ie -coap-eap-p oo -o -concep , 2022. URL h ps://
gi hub.com/danga ciaca illo/d a -ie -coap-eap-p oo -o -concep .
[31] OpenSSL Documen a ion, (s. .). URL h ps://docs.openssl.o g/mas e /.
[32] Uni e sally Unique IDen i ie s (UUIDs), 2024. URL h ps://da a acke .
ie .o g/doc/ c9562/.
Bibliog a ía 63
[33] Ge ing s a ed wi h you Raspbe y Pi, (s. .). URL h ps://www. aspbe ypi.
com/documen a ion/compu e s/ge ing-s a ed.h ml.
[34] Abou OP-TEE. URL h ps://op ee. ead hedocs.io/en/la es /gene al/
abou .h ml.
[35] Ami Nadige . OPTEE, 2023. URL h ps://www.linkedin.com/pulse/
ee-op ee-ami -nadige .
[36] Build and un, (s. .). URL h ps://op ee. ead hedocs.io/en/la es /
building/p e equisi es.h ml.
[37] Jose Manuel Me los Espín. CERTIFY-OP-TEE, 2024. URL h ps://
an s-gi lab.in .um.es/jmanuel/ce i y-op- ee.
[38] Sa a Ma heu, S e ano Sebas io, An onio Ska me a, Ricca do O izio, S e anos Vasi-
leiadis, Vasilis Kalos, Ka ha ina Mülle , Thomas G übl, Rosella Omana Mancilla,
Simon Tuck, Thomas Bocek, Vincenzo Cuomo, Roland A oui, S eede i Beena,
Luigi Coppolino, Robe o Na done, Dinesh Sha ma, Rohi Boha a, Ja ie Pa a-
Domínguez, and Ja ie P ie o. Ac i e Secu i y o Connec ed De ice Li ecycle:
The CERTIFY A chi ec u e. In Rashid Mehmood, Guille mo He nández, Isa-
bel P aça, Ja oslaw Wika ek, Roussanka Loukano a, A sénio Mon ei o dos Reis,
An onio Ska me a, and Eleono a Lomba di, edi o s, Dis ibu ed Compu ing and
A i icial In elligence, Special Sessions I, 21s In e na ional Con e ence, pages
301–310, Cham, 2025. Sp inge Na u e Swi ze land. ISBN 978-3-031-76459-2.
[39] E ic Resco la. HTTP O e TLS, 2000. URL h ps://da a acke .ie .o g/
doc/h ml/ c2818.
[40] Hugo K awczyk, Mihi Bella e, and Ran Cane i. HMAC: Keyed-Hasing o Mes-
sage Au hen ica ion, 1997. URL h ps://da a acke .ie .o g/doc/h ml/
c2104.
[41] E angelos Haleplidis, Kos as Pen ikousis, Spy os Denazis, Jamal Hadi Salim, Da-
id Meye , and Odysseas Kou opa lou. So wa e-De ined Ne wo king (SDN): La-
ye s and A chi ec u e Te minology, 2015. URL h ps://da a acke .ie .
o g/doc/h ml/ c7426.
[42] Ex ensible Ma kup Language (XML) 1.0 (Fi h Edi ion), 2008. URL h ps:
//www.w3.o g/TR/xml/.
[43] xml.e ee.Elemen T ee - The Elemen T ee XML API. URL h ps://docs.
py hon.o g/3/lib a y/xml.e ee.elemen ee.h ml.
[44] Ch is M. Lon ick and Ta u Ylonen. The Secu e Shell (SSH) P o ocol A chi ec u e,
2006. URL h ps://da a acke .ie .o g/doc/h ml/ c4251.
A. Anexo I. Fiche o MUD gene ado
{
"ie -mud:mud": {
"mud- e sion": 1,
"mud-u l": "h ps://www.example.com/you mud ile.json",
"las -upda e": "2024-12-18T21:07:00+01:00",
"cache- alidi y": 48,
"ex ensions": [
"umu-mspl-lis :mspls"
],
"is-suppo ed": ue,
"modelname": " aspbe y pi 3 model B",
"sys emin o": " aspbe yy pi 3 model B cu en MUD File",
" om-de ice-policy": {
"access-lis s": {
"access-lis ": [
{
"name": "ou bound-s ic ed-communica ion"
}
]
}
},
" o-de ice-policy": {
"access-lis s": {
"access-lis ": [
{
"name": "inbound-s ic ed-communica ion"
}
]
}
}
},
"ie -access-con ol-lis :acls": {
"acl": [
{
"name": "ou bound-s ic ed-communica ion",
" ype": "ip 4-acl- ype",
"aces": {
"ace": [
{
"name": "ou pu - ule",
"ma ches": {
"ip 4": {
"des ina ion-ip 4-ne wo k": "192.168.100.0/24",
"p o ocol": 6
},
" cp": {
"ie -mud:di ec ion-ini ia ed": " om-de ice",
"des ina ion-po ": {
"ope a o ": "eq",
"po ": 443
}
}
65
},
"ac ions": {
" o wa ding": "accep "
}
}
]
}
},
{
"name": "inbound-s ic ed-communica ion",
" ype": "ip 4-acl- ype",
"aces": {
"ace": [
{
"name": "inpu - ule",
"ma ches": {
"ip 4": {
"sou ce-ip 4-ne wo k": "192.168.100.0/24",
"p o ocol": 6
},
" cp": {
"ie -mud:di ec ion-ini ia ed": " o-de ice",
"sou ce-po ": {
"ope a o ": "any",
"po ": "*"
}
}
},
"ac ions": {
" o wa ding": "accep "
}
}
]
}
}
]
},
"umu-mspl-lis :mspls": {
"mspl": [
{
"name": "mspl_change_signa u e",
" ype": "so wa e-mspl- ype",
"con igu a ion": {
"capabili y": "so wa e-p o ec ion",
" ule-se -con igu a ion": {
"name": "change_signa u e_ ule_se ",
"con igu a ion- ule": {
"name": "change_signa u e_ ule",
"con igu a ion-ac ion": {
"so wa e-p o ec ion-ac ion": {
"so wa e-p o ec ion- ype": "USE-HMAC"
}
}
}
}
}
},
{
"name": "mspl_ il e ing",
" ype": "ip 4-mspl- ype",
"con igu a ion": {
"capabili y": "Fil e ing_L4",
" ule-se -con igu a ion": {
"name": " il e ing_ ule_se ",

66 Anexo I. Fiche o MUD gene ado
"con igu a ion- ule": [
{
"name": " il e ing_ ule",
"con igu a ion-ac ion": {
" il e ingAc ion": {
" il e ing-ac ion- ype": "ALLOW"
}
},
"con igu a ion-condi ion": {
" il e ing-con igu a ion-condi ion": {
"packe - il e -condi ion": {
"sou ce_dnsname": "boo s apping-se e .umu",
"des ina ion_dnsname": " aspbe y-pi-3-modelB-TFG.umu←-
,→",
"sou ce_po ": "any",
"des ina ion_po ": "any",
"di ec ion": "INBOUND",
"p o ocol_ ype": "6"
}
}
}
}
]
}
}
}
]
}
}
B. Anexo II. T aducción del iche o
MUD a MSPL
<!-- MSPL 1 – Pe mi i á ico con la ed 192.168.100.0/24 -->
<?xml e sion="1.0" encoding="UTF-8"?>
<mspl>
<name ype="s ">mspl_example</name>
<con igu a ion ype="dic ">
<capabili y ype="s ">Fil e ing_L4</capabili y>
< ule-se -con igu a ion ype="dic ">
<name ype="s "> ule_se a963b7a3-1dcb-49e2-8ed6-3 b9a1c37c64</name>
<de aul -ac ion ype="s ">deny</de aul -ac ion>
<con igu a ion- ule ype="dic ">
<ou pu - ule ype="dic ">
<ex e nal-da a ype="dic ">
<p io i y ype="in ">1</p io i y>
</ex e nal-da a>
<con igu a ion-ac ion ype="dic ">
< il e ing-ac ion ype="dic ">
< il e ing-ac ion- ype ype="s ">allow</ il e ing-ac ion- ype>
</ il e ing-ac ion>
</con igu a ion-ac ion>
<con igu a ion-condi ion ype="dic ">
< il e ing-con igu a ion-condi ion ype="dic ">
<packe - il e -condi ion ype="dic ">
<des ina ion-add ess ype="s ">192.168.100.0/24</des ina ion-←-
,→add ess>
<des ina ion-po ype="s ">eq 443</des ina ion-po >
<di ec ion ype="s ">OUTBOUND</di ec ion>
<p o ocol- ype ype="s ">6</p o ocol- ype>
</packe - il e -condi ion>
</ il e ing-con igu a ion-condi ion>
</con igu a ion-condi ion>
<name ype="s ">ou pu - ule</name>
</ou pu - ule>
<inpu - ule ype="dic ">
<ex e nal-da a ype="dic ">
<p io i y ype="in ">1</p io i y>
</ex e nal-da a>
<con igu a ion-ac ion ype="dic ">
< il e ing-ac ion ype="dic ">
< il e ing-ac ion- ype ype="s ">allow</ il e ing-ac ion- ype>
</ il e ing-ac ion>
</con igu a ion-ac ion>
<con igu a ion-condi ion ype="dic ">
< il e ing-con igu a ion-condi ion ype="dic ">
<packe - il e -condi ion ype="dic ">
<sou ce-add ess ype="s ">192.168.100.0/24</sou ce-add ess>
<sou ce-po ype="s ">any *</sou ce-po >
<di ec ion ype="s ">INBOUND</di ec ion>
<p o ocol- ype ype="s ">6</p o ocol- ype>
</packe - il e -condi ion>
68 Anexo II. T aducción del iche o MUD a MSPL
</ il e ing-con igu a ion-condi ion>
</con igu a ion-condi ion>
<name ype="s ">inpu - ule</name>
</inpu - ule>
</con igu a ion- ule>
</ ule-se -con igu a ion>
</con igu a ion>
</mspl>
<!-- MSPL 2 – Polí ica de cambio de algo i mo de i ma -->
<?xml e sion="1.0" encoding="u -8"?>
<mspl>
<con igu a ion>
<capabili y>so wa e-p o ec ion</capabili y>
< ule-se -con igu a ion>
<con igu a ion- ule>
<con igu a ion-ac ion>
<so wa e-p o ec ion-ac ion>
<so wa e-p o ec ion- ype>USE-HMAC</so wa e-p o ec ion- ype>
</so wa e-p o ec ion-ac ion>
</con igu a ion-ac ion>
<name>change_signa u e_ ule</name>
</con igu a ion- ule>
<name>change_signa u e_ ule_se </name>
</ ule-se -con igu a ion>
</con igu a ion>
<name>mspl_change_signa u e</name>
< ype>so wa e-mspl- ype</ ype>
</mspl>
<!-- MSPL 3 – Pe mi i á ico en an e desde se ido de boos apping de la UMU -->
<?xml e sion="1.0" encoding="u -8"?>
<mspl>
<con igu a ion>
<capabili y>Fil e ing_L4</capabili y>
< ule-se -con igu a ion>
<con igu a ion- ule>
<con igu a ion-ac ion>
< il e ingAc ion>
< il e ing-ac ion- ype>ALLOW</ il e ing-ac ion- ype>
</ il e ingAc ion>
</con igu a ion-ac ion>
<con igu a ion-condi ion>
< il e ing-con igu a ion-condi ion>
<packe - il e -condi ion>
<des ina ion_dnsname> aspbe y-pi-3-modelB-TFG.umu</←-
,→des ina ion_dnsname>
<des ina ion_po >any</des ina ion_po >
<di ec ion>INBOUND</di ec ion>
<p o ocol_ ype>6</p o ocol_ ype>
<sou ce_dnsname>boo s apping-se e .umu</sou ce_dnsname>
<sou ce_po >any</sou ce_po >
</packe - il e -condi ion>
</ il e ing-con igu a ion-condi ion>
</con igu a ion-condi ion>
<name> il e ing_ ule</name>
</con igu a ion- ule>
<name> il e ing_ ule_se </name>
</ ule-se -con igu a ion>
</con igu a ion>
<name>mspl_ il e ing</name>
< ype>ip 4-mspl- ype</ ype>
</mspl>
C. Anexo III. Base de da os del
De ice and Domain Manage
En es e anexo se incluye una imagen sob e el con enido de la base de da os del
De ice and Domain Manage una ez la Raspbe y Pi 3 Model B ha comple ado el
p oceso de boo s apping. El mo i o de añadi es e anexo es que en la sección 4.4 es
imposible coloca la imagen de o ma que es a pueda se legible. Po ello, hacemos uso
del o ma o apaisado en es e anexo pa a pode isualiza el con enido de la base de
da os.