X.509-gebaseerde apparaatverificatie in Eclipse Hono

De afgelopen maanden stonden de media vol met berichten over onveilige IoT-apparaten die zelfs niet aan de meest elementaire beveiligingseisen voldeden. Een van de geuite zorgen was de vertrouwelijkheid van gegevens die worden overgedragen van apparaten naar cloudservices die door de fabrikanten worden geleverd. In veel gevallen worden gegevens volledig onversleuteld over openbare netwerken verzonden, wat nogal verrassend is, aangezien alle populaire op TCP/IP gebaseerde transportprotocollen die worden gebruikt in de hedendaagse IoT-apparaten (bijv. HTTP en MQTT) de onderhandeling en het gebruik van een veilig (versleuteld) transportkanaal door middel van Transport Layer Security (TLS).

Eclipse Hono heeft vanaf het begin het gebruik van TLS in zijn HTTP- en MQTT-protocoladapters ondersteund. De onlangs uitgebrachte mijlpaal van 0,9-M2 heeft ondersteuning toegevoegd voor de authenticatie van apparaten die een X.509-clientcertificaat gebruiken als onderdeel van de TLS-handshake voor zowel de HTTP- als de MQTT-adapter. Hierdoor kunnen apparaten een privé/openbaar sleutelpaar gebruiken in plaats van een gebruikersnaam en wachtwoord om zichzelf te authenticeren bij de protocoladapters.

Oproep aan alle ontwikkelaars

Europa's grootste IoT-hackathon keert terug naar Berlijn op 14-15 mei 2019. Sluit je aan bij meer dan 700 ontwikkelaars in verschillende domeinspecifieke hackuitdagingen om te hacken, spelen, leren, plezier hebben en nieuwe vrienden maken van over de hele wereld!

Doe mee met de IoT-hackathon

In deze blogpost zal ik u door een volledig voorbeeld leiden van hoe u een huurderspecifiek vertrouwensanker kunt maken en registreren. , maak een certificaat voor een apparaat, registreer de onderscheiden naam en, ten slotte, gebruik het certificaat om het apparaat te authenticeren met Hono's MQTT-protocoladapter. In de rest van dit bericht ga ik ervan uit dat je een algemeen begrip hebt van op RSA gebaseerde cryptografie en in het bijzonder de rollen die privé- en openbare sleutels spelen. Ter referentie:RFC 5280 definieert alle technische details van X.509.

Waarom clientcertificaten?

Wanneer wachtwoorden worden gebruikt voor het verifiëren van apparaten, moet het wachtwoord van elk apparaat worden geregistreerd bij Hono's Credentials-service, zodat de protocoladapters het wachtwoord dat door het apparaat wordt gepresenteerd tijdens de authenticatie kunnen vergelijken met de geregistreerde hash van het wachtwoord.

Een van de voordelen van het gebruik van clientcertificaten voor het verifiëren van apparaten is dat het niet langer nodig is om individuele geheimen (wachtwoorden) voor apparaten met Hono te registreren. In plaats daarvan is het voldoende om één vertrouwensanker te registreren voor een tenant die vervolgens kan worden gebruikt om de identiteit van alle apparaten van de tenant te verifiëren als onderdeel van de TLS-handshake. Om dit te laten werken, moeten de clientcertificaten die door de apparaten worden gebruikt, een digitale handtekening bevatten die kan worden gevalideerd met behulp van de openbare sleutel die dient als het vertrouwensanker van de huurder.

Maak een certificeringsinstantie voor een tenant

De eerste stap is daarom het maken van het openbare/private sleutelpaar van de huurder dat zal worden gebruikt om de clientcertificaten te ondertekenen die door de apparaten van de huurder worden gebruikt.

$ openssl genrsa -out tenant-key.pem 4096 $ openssl req -x509 -key tenant-key.pem -out tenant-cert.pem -days 365 -subj "/O=ACME Inc./CN=Sensors"

De DN-naam van het onderwerp die is ingesteld met de parameter `-subj' kan elke geldige DN-naam X.500 bevatten. Om het echter eenvoudig te houden, dient u zich te onthouden van het gebruik van attribuuttypes behalve `CN`, `L`, `ST`, `O`, `OU`, `C`, `STREET`, `DC`, `UID`.

Registreer de huurder

Nu de sleutels zijn gemaakt, kunnen we een huurder registreren met behulp van de openbare sleutel als vertrouwensanker.

Voor het gemak gebruiken we de Hono Sandbox. Elke andere (lokale) installatie met versie 0.9-M2 of hoger zou echter ook moeten werken.

Vervang in de onderstaande opdrachten de 'ACME'-tenant-ID door een ID van uw eigen keuze. Dit is belangrijk omdat Hono de uniciteit van tenant-id's afdwingt. Elke identifier kan daarom maar één keer per Hono-instantie worden geregistreerd.

De eerste drie opdrachten definiëren enkele variabelen voor later gebruik:de tenant-id, de DN-naam van het certificaat en de met Base64 gecodeerde openbare sleutel. De variabelen worden vervolgens in de opdracht gebruikt om het trust anchor bij de nieuwe tenant te registreren.

$ HUURDER="ACME" $ SUBJECT=$(openssl x509 -in tenant-cert.pem -noout -subject -nameopt RFC2253 | sed s/^subject=//) $ PK=$(openssl x509 -in tenant-cert.pem -noout -pubkey | sed /^---/d | sed -z 's/\n//g') $ cat < huurder.json {"tenant-id":"$TENANT", "trusted-ca":{"subject-dn":"$SUBJECT", "public-key":"$PK"}} EOS $ curl -i -H 'Content-Type:application/json' -H 'Expect:' --data-binary @tenant.json https://hono.eclipse.org:28443/tenant

Maak een apparaatcertificaat

De volgende stap is het maken van een sleutelpaar voor het apparaat en het bijbehorende clientcertificaat, dat wordt ondertekend door de privésleutel van de huurder.

$ openssl genrsa -out device-key.pem 4096 $ openssl req -new -key device-key.pem -subj "/O=ACME Inc./CN=Hot Fuzz Device" | openssl x509 -req -days 365 -out device-cert.pem -CA tenant-cert.pem -CAkey tenant-key.pem -CAcreateserial

Nogmaals, zorg ervoor dat u geen andere attributen gebruikt dan `CN`, `L`, `ST`, `O`, `OU`, `C`, `STREET`, `DC`, `UID` in het onderwerp voorname naam.

Registreer het apparaat

We kunnen nu een willekeurige apparaat-ID gebruiken om het apparaat bij de huurder te registreren.

$ curl -i -H 'Content-Type:application/json' --data-binary '{"device-id":"hot-fuzz"}' https://hono.eclipse.org:28443/registration/$ HUURDER

Registreer de onderwerp-DN van het apparaat

De laatste stap is het registreren van de DN-naam van het apparaat. Zorg er opnieuw voor dat u dezelfde tenant- en apparaat-ID's gebruikt als hierboven.

$ SUBJECT=$(openssl x509 -in device-cert.pem -noout -subject -nameopt RFC2253 | sed s/^subject=//) $ cat < credentials.json {"device-id":"hot-fuzz", "type":"x509-cert", "auth-id":"$SUBJECT", "geheimen":[{}]} EOS $ curl -i -H 'Content-Type:application/json' --data-binary @credentials.json https://hono.eclipse.org:28443/credentials/$TENANT

Test de verbinding

Nu het apparaat is geregistreerd, is het tijd om verbinding te maken met de MQTT-adapter met behulp van het nieuw gemaakte clientcertificaat en enkele gegevens te publiceren.

Eerst starten we een consument voor de huurder waarvoor we het apparaat hebben geregistreerd. U kunt de client downloaden van de Hono-website:

$ java -jar hono-cli-*-exec.jar --hono.client.host=hono.eclipse.org --hono.client.port=15671 --hono.client.tlsEnabled=true --hono.client. gebruikersnaam=consumer@HONO --hono.client.password=verysecret --spring.profiles.active=ontvanger --tenant.id=$TENANT

In de laatste stap gebruiken we de Eclipse Mosquitto-opdrachtregelclient om enkele telemetriegegevens te publiceren:

$ mosquitto_pub -h hono.eclipse.org -p 8883 --capath /etc/ssl/certs/ --cert device-cert.pem --key device-key.pem -q 1 -t telemetrie -m "Hallo daar"

Als alles goed gaat, zou je moeten kunnen zien dat de gegevens worden gelogd op de console in de terminal waar je de consument hebt gestart.

Het apparaat kan ook HTTP gebruiken om gegevens te publiceren:

$ curl -i --cert device-cert.pem --key device-key.pem -H 'Content-Type:plain/text' -H 'Expect:' --data-binary 'Hallo daar' https:// hono.eclipse.org:8443/telemetry