3.2. Dise˜no de m´odulos del sistema
3.2.8. Dise˜no de m´odulo [M8]: L´ogica de acci´on de estacionamientos
3.2.8.5. Rutina de acuerdo de llaves privadas(PK) para ins-
En pos de la escabalibilidad del sistema, se deben dise˜nar las PDE y EB de forma que su configuraci´on de f´abrica con sus respectivas llaves privadas(PK) y LDI no sig- nifique un riesgo para el servicio. Esto es, si se necesitara implementar un gran n´umero de EB y PDE, su configuraci´on podr´ıa resultar en un proceso tedioso y arriesgado en el sentido de que ser´ıa muy f´acil equivocarse.
net se tienen dos alternativas:
1. El algoritmo de Diffie-Hellman [33], que soluciona al problema del inicio de comunicaci´on en un esquema sim´etrico.
2. Configurar las EB desde f´abrica con un secreto compartido con el servidor para iniciar el proceso de comunicaci´on y acordar las llaves.
Para efectos de prototipo, se utiliza la segunda alternativa. Cuando el sistema est´e en producci´on, se puede decidir si la primera o la segunda alternativa es la m´as ade- cuada en t´erminos de seguridad, i.e. la implementaci´on de la primera alternativa no debe impedir que la segunda sea implementable.
El proceso de acuerdo de llaves se describe a continuaci´on: 1. La EB nueva debe estar configurada para:
Publicar en un t´opico del broker MQTT designado para iniciar el proceso de acuerdo de llaves con el servidor, llamado t´opico 0.
Suscribirse a un t´opico mediante el cual recibir´a las PK desde el servidor, llamado t´opico 1.
2. El acuerdo de llaves lo inicia la EB nueva mediante:
La publicaci´on de un mensaje en el t´opico 0 que la autentique con el ser- vidor y la identifique de forma ´unica.
La suscripci´on al t´opico 1.
3. Como cada IoTD de las EB cuenta con conexi´on WiFi, cada una de ellas cuenta tambi´en con una direcci´on MAC ´unica, la cual ser´a utilizada para identificar la EB con el servidor.
4. La EB debe utilizar las PK iniciales para generar un n´umero con el PRNG, de forma que el servidor haga lo mismo y pueda autenticar a la EB.
5. El mensaje publicado por la EB en el t´opico 0 estar´a compuesto entonces por su direcci´on MAC y el n´umero generado por el PRNG con las PK.
6. Antes de publicar el mensaje, la EB debe suscribirse al t´opico 1:
Como el mensaje publicado en el t´opico 0 contiene la direcci´on MAC y esta es ´unica, se utilizar´a para suscribirse al t´opico 1.
Esto es debido a que el servidor puede publicar en el t´opico 1 con la segu- ridad que solo estar´a enviando las PK a la EB correspondiente.
Para suscribirse al t´opico 1, debe tomar los seis pares hexadecimales de MAC, transformarlos a base decimal y utilizarlos como los par´ametros del PRNG.
El n´umero resultante de aquella operaci´on es el nombre del t´opico 1, al cual la EB se suscribe.
7. El nombre del t´opico 0 es el n´umero generado por el PRNG con las PK iniciales. 8. El servidor debe estar esperando un mensaje en el t´opico 0, mediante el cual
recibe peticiones de acuerdo de llaves.
9. Cuando el servidor lea el mensaje, debe separar el MAC del n´umero generado por el PRNG.
10. Luego debe generar un n´umero con las PK y el PRNG y compararlo con el que viene en el mensaje.
11. Si coinciden, procede al siguiente paso. En caso contrario, registra el incidente en la base de datos y no contin´ua.
12. El servidor genera las PK y las almacena junto con el MAC y el t´opico 1 en la base de datos. Asigna adem´as un ID ´unico a la EB en el servidor, de forma que sirva para futuros cambios en las llaves y b´usqueda en la base de datos.
13. El servidor utiliza el MAC para publicar las PK nuevas en el t´opico 1 de la misma forma que hizo la EB para suscribirse; descompone el MAC y lo utiliza como par´armetros del PRNG.
14. El servidor comienza entonces a publicar las PK en el t´opico 1.
15. Al terminar, el servidor queda a la espera de la confirmaci´on de recepci´on desde la EB. Para ello se suscribe al t´opico 1, donde la EB publicar´a su mensaje de confirmaci´on.
16. La EB lee las PK en la medida que se van publicando en el t´opico 1 y las almacena.
17. Al recibir todas las PK la EB debe informar al servidor que el almacenamiento fue exitoso mediante un mensaje de confirmaci´on.
18. Este mensaje es el n´umero generado por PRNG con las PK nuevas. 19. La EB publica este mensaje en el t´opico 1.
20. El servidor lee el mensaje y utiliza las PK nuevas para el PRNG. Si su resultado coincide con el mensaje, se actualiza el estado de la EB en la base de datos como ”exitosamente registrado” y se da por terminado el proceso de acuerdo de llaves.
Se debe mantener la suscripci´on en el t´opico 1, a pesar de que las PK cambien con el tiempo. Dicho t´opico sirve para tener un canal de comunicaci´on autenticado mediante el uso de MAC, lo que puede servir para monitoreo de las estaciones.