Seguridad en IIoT/Edge/Fog

160 views
Skip to first unread message

gerardo gimenez

unread,
Apr 19, 2022, 10:08:50 AMApr 19
to embeb...@googlegroups.com
Hola,

Estoy viendo el tema de seguridad para IIOT.

¿Alguien conoce alguna bibliografía buena o algún referente sobre el tema?

Porque me cuesta ver cuál sería el estándar de mercado y si la premisa de "cuanto más seguridad mejor" es realmente requerida.

La pregunta es: ¿qué protocolos debería manejar para sacar algo al mercado?


Alguien tiene esta charla

Octava Reunión LMAG: "Comunicación Segura para Internet de las Cosas"  por Ing. Jorge Eterovic 


Saludos







--
Giménez Gerardo Daniel.


Libre de virus. www.avast.com

Adrian Pardini

unread,
Apr 19, 2022, 10:14:53 AMApr 19
to embeb...@googlegroups.com
On Tue, Apr 19, 2022 at 11:10 AM gerardo gimenez
<gerardo...@gmail.com> wrote:
>
> Hola,
> Estoy viendo el tema de seguridad para IIOT.
> ¿Alguien conoce alguna bibliografía buena o algún referente sobre el tema?
> Porque me cuesta ver cuál sería el estándar de mercado y si la premisa de "cuanto más seguridad mejor" es realmente requerida.

Buenas Gerardo,

Carlos Pantélides / pelucaKiller seguro pueda orientarte
https://seguridad-agile.blogspot.com/
(está acá también)

--
Adrián Pardini

Telmo Moya

unread,
Apr 20, 2022, 10:14:46 AMApr 20
to Embebidos32
Hola Gerardo, te dejo link de un paper en el que podés encontrar referencias al tema:

Saludos!
Telmo

Rossi Federico

unread,
Apr 20, 2022, 9:14:13 PMApr 20
to Embebidos32

Carlos Pantelides

unread,
Apr 21, 2022, 7:19:41 AMApr 21
to Embebidos32
Esta conversación me genera algunas intrigas, ideas, dudas, reflexiones, que paso a compartir, más en modo brainstorming que sistemático.

Si el asunto fuera "Electrónica de potencia", dada la naturaleza de este grupo, nadie se preguntaría si quien hace la pregunta sabe de electrónica básica analógica.  

De hecho, yo mismo muchas veces me veo en la situación de preguntar cosas para las cuales no tengo bien las bases. Por ejemplo, una vez fuí al LABI y le pregunté a algún electrónico "si tengo un transformador 220-110, ¿lo puedo conectar al revés y usarlo como 110-220?" (contemplando claramente que de ser posible la potencia manejada no sería la misma, creo) y no pude dilucidar si la persona no sabía o no entendí los fundamentos de su respuesta negativa.


Ahora yendo a las preguntas originales, las que puedo contestar y no siendo una persona muy conocedora de normas y para disparar que quien sepa más corrija:

*) "cuanto más seguridad mejor"

En general, ocurre con toda característica (costo, performance, eficiencia, tiempo de respuesta, usabilidad, lo que sea), depende de la interrelación con las otras características.

Por ejemplo, el caso de RFID con Mifare (la que que usa la tarjeta sube), es insegura, se puede romper la criptografía (https://www.google.com/search?q=mifare+classic+1k+vulnerability) con lo cual no hay manera de evitar que sea leida, modificada y clonada.

En la situación original de SUBE, podías cambiar el saldo y no podían cambiar las tarjetas, aunque justo se estaban haciendo públicas las vulnerabilidades en el momento de la implantación original, me imagino que alguna cabeza iba a rodar.

Se agregó un control compensatorio para detectar el comportamiento divergente entre la tarjeta y los registros, entonces en poco tiempo se detectaba y bloqueaba la tarjeta, lo mismo por si estuviera clonada. Luego, creo, dejé de prestarle atención al tema, le agregaron criptografía extra para evitar que la lectura obtenga datos significativos y la escritura tenga sentido.

De todos modos se puede seguir clonando (calculo, aunque hay que usar una tarjeta especial más cara que permite números de serie arbitrarios) y se sigue detectando el uso anómalo (supongo, no existe más el negocio de las tarjetas clonadas hasta donde he oido).

La interrelación en este caso es: "acabo de desplegar un sistema que ya es legacy, cómo me las arreglo".

Estaba por decir que lo que diferencia la seguridad de las otras características es la presencia de adversarios, pero si considerás el escenario en que un competidor introduce un sistema equivalente más rápido/barato/eficiente, bien podés equiparar al competidor con cualquier amenaza de seguridad.


*) "cuanto más seguridad mejor" es realmente requerida

Supongo que si uno debe certificar una norma debe cumplirla independientemente de las interrelaciones previas. O sea, si dice, "las claves deben tener una longitud mínima de 16 caracteres", aunque eso afecta la usabilidad hay que cumplirlo y listo. Si dice "hay que cumplir con tal nivel criptográfico", habrá que balancear el costo del componente, el tiempo de procesamiento, el consumo y alguno se va a disparar.

                 
Retomando el tema del comienzo, habiendo expuesto todo esto espero que ya estemos en sintonía para poder poder decir que a lo que quiero ir es que para un tema de seguridad en particular hay que estar bastante familiarizado con seguridad en general, tener las bases y ahora te puedo preguntar sin resultar agresivo, ¿sabés algo de seguridad en general? y responder:


*) ¿Alguien conoce alguna bibliografía buena o algún referente sobre el tema?

No me puedo postular como referente de IIOT ni es exactamente sobre el tema, pero si te puedo recomendar dos libros, en este orden de estudio:

Security Engineering: A Guide to Building Dependable Distributed Systems (2ed) - Ross Anderson
Hardware Security: A Hands-on Learning Approach – Bhunia, Tehranipoor
        

Sigamos, saludos

gerardo gimenez

unread,
Apr 21, 2022, 10:31:00 AMApr 21
to embeb...@googlegroups.com
Hola,

Gracias a todos por sus respuestas, hoy me dedicaré a leer toda la info que enviaron.

Para despejarte las dudas, Carlos. Me declaro lego en seguridad, por lo menos hasta que se pruebe lo contrario. ja!

La verdad que es un tema que nunca le di importancia, y ahora es un "hot topic" en embebidos. Así que toca aprender.

Allá por 2005 cuando salieron los primeros stacks TCP/IP de 8 bits sobre ethernet a nadie le importaba la seguridad, lo que importaba es que funcionara. jaja!!
Después relegué todo a los módulos y no volví a ver una maldita stack de nada. Y ahora por diferentes motivos, seguridad entre ellos, vuelvo a manejar el stack y capa física.

Pero bueno, más allá de las charlas de Chema Alonzo y algunos papers de Peter Shor tratando de vender sus encriptaciones no hackeables por algoritmos cuánticos, no vi mucho más del tema. 

Algo concreto:

Para empezar estoy trabajando en MQTT cripto, sobre TCP/IPv4 y TLS con user y pass. Después veré si sigo con HTTPS e IPv6.¿ Alguien tiene experiencia con IPv6 en embedded? Se hará una charla sobre el tema dentro de poco.

Varios ponen en duda la vida de MQTT. ¿Qué piensan de esto?

....


Dejo algo de color, que me recomendó Google despues de las busquedas en seguridad:

Tiene sentido lo que hizo, no se si le creo del todo. Pero de ser así "alto hacker" jaja



Saludos



--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/a11f6113-be2b-4046-99b7-960d7fc50824n%40googlegroups.com.


--
Giménez Gerardo Daniel.

Pablo Lode

unread,
Apr 22, 2022, 3:45:43 PMApr 22
to Embebidos32


Hola Gerardo, como es eso de   "Varios ponen en duda la vida de MQTT. ¿Qué piensan de esto?"
, recién arranco con MQTT y ya lo están jubilando?? ja, que otro protocolo se estará imponiendo??

gerardo gimenez

unread,
Apr 22, 2022, 7:15:20 PMApr 22
to embeb...@googlegroups.com
jaja!! Tranqui, aprendé tranquilo.

Pero si es verdad que hay cosas que no son congruentes y algunos piensan que con el tiempo todo convergerá a HTTP e IPv6.

Las razones son varias.... La gente de IT tiene problemas para integrar los sistemas, y como siempre, la solución más rápida es meter más fierros. Entonces con más fierros MQTT pierde un poco el espíritu...

Lamentablemente los electrónicos estamos haciendo lo mismo. Ponés un Cortex M4 para la placa principal y después metés un módulo de wifi que tiene un Cortex A7 adentro.... un A7 puede manejar HTTP, tranki!!

Lo único que se podría objetar es el "tiempo real". Pero ya hay en el mercado cosas como el MP1 de ST que es un Cortex A7 con un M4 al lado. Entonces corrés tu RTOS en el M4 y para enviar por wifi solo tendrías que escribir en una posición de memoria específica y listo...ni UART, ni SPI, ni nada... AMBA derecho

Así que la alta integración en los componentes y la fácil integración en IT, estarían llevando todo a HTTP.

y si te pones a pensar... cosas como 6lowpan, IPv6 sobre capa "Zigbee", parece que tienen razón que todo va a converger a HTTP IPv6...

En cuando se pongan de acuerdo y estandarizan... por ahí MQTT no pasa el filtro. 

Pero bueno.. yo qué sé.  Por el momento MQTT y kubernetes.


Saludos.




On Fri, 22 Apr 2022 at 16:45, Pablo Lode <pabl...@gmail.com> wrote:


Hola Gerardo, como es eso de   "Varios ponen en duda la vida de MQTT. ¿Qué piensan de esto?"
, recién arranco con MQTT y ya lo están jubilando?? ja, que otro protocolo se estará imponiendo??

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.


--
Giménez Gerardo Daniel.

Ivan Camilo Aranda C.

unread,
Apr 24, 2022, 8:58:38 AMApr 24
to embeb...@googlegroups.com
Buen día, 

Respondiendo el post original creo que la seguridad siempre está sobre la balanza, es importante siempre hacer un threat modeling y una clasificación de riesgos para entender un poco de que controles puedes aplicar, no siempre el usar la última tecnología es mejor y sobre todo en embebidos, ya que muchas veces siempre están limitados por sus características físicas. Te puedo recomendar revisar el framework de OWASP en IOT (1) IoT aquí podrás identificar los principales problemas que afectan la seguridad en IoT. 

Ahora he visto un buen soporte de seguridad para MQTT y varias API en la nube que te permite integrar de manera fácil estos protocolos/dispositivos y sobre todo con una muy buena postura de seguridad, lo hablo desde la experiencia (2). IPv6 la verdad creo que aún falta rato para que se masifique su uso, pero no está demás empezar a probar en un ambiente local.

Por otro lado, recomiendo siempre aplicar la seguridad por capas, teniendo siempre en cuenta todos los componentes del sistema.


Saludos.


Fuentes:









--
IVAN CAMILO ARANDA CASAS
P Please consider the environment before printing this e-mail  

Miguel Grassi

unread,
Apr 24, 2022, 3:32:11 PMApr 24
to embeb...@googlegroups.com
Si la industria para la que estás trabajando no exige estándares particulares, hay muchas opciones para elegir. Para aportar mis dos centavos a la conversación sobre MQTT, el esquema basado en criptografía mediante TLS/SSL, ya sea con certificados o PSK, es muy sólido frente a los tipos de ataques más comunes por la vía de la red (man in the middle y todas las variantes similares de cyber ataque). Es fácil de implementar y hay muchas librerías disponibles, así como soporte del lado de los brokers, Mosquitto incluido. 

Obviamente, esto es insuficiente frente a atacantes con acceso físico al hardware IoT, que puedan clonar dispositivos, descargar o modificar registros y datos en la memoria, leer las claves de PSK, etc. Pero para eso cada fabricante de micros tiene sus propias alternativas de seguridad, tales como encriptado de la flash, booteo seguro, firma de binarios, etc. En mi caso, combinando ambas cosas he logrado niveles de seguridad más que suficientes para aplicaciones no demasiado críticas, pero susceptibles de algún ataque.

Saludos,

--

Miguel


Reply all
Reply to author
Forward
0 new messages