AVR-IoT und PIC-IoT – Entwicklungsboards von Microchip
über
Wie allseits bekannt hat Microchip 2016 Atmel übernommen und bietet jetzt nicht nur PIC-Mikrocontroller, sondern auch Atmel-Produkte einschließlich der AVR-Mikrocontroller an. Microchip wird die AVR-Serie nicht nur beibehalten, sondern sogar erweitern und neue Funktionen und Merkmale hinzuzufügen. Tools und Evaluierungsboards enthalten nun also das Beste von allen Produkten, die von Microchip angeboten werden. In diesem Kontext möchten wir Ihnen die Entwicklungsboards AVR-IoT und PIC-IoT WA von Microchip vorstellen, die der WLAN-Anbindung zu AWS IoT Core (Amazon Web Services) dienen.
Die ersten Schritte in die Welt von Cloud-Storage und -Computing sind nicht ganz trivial. Der Betrieb einer sicheren Datenübertragung zu einem Cloud-Service wie AWS bei geringem Energiebedarf kann für Entwickler ziemlich herausfordernd ausfallen. Microchip bietet hierfür zwei Entwicklungs-Boards an, die den Zugang zu AWS IoT Core ermöglichen und dabei eine sichere Kommunikation über WLAN bei geringem Energieverbrauch bieten und die nötige Entwicklungszeit verkürzen. Bevor wir die Hard- und Software detailliert beleuchten, werden wir zunächst den Lieferumfang zeigen und überlegen, was man von diesen Lösungen erwarten kann.
Was ist drin?
Auf den beiden fast identischen Kartons (Bild 1) ist ein Link und ein QR-Code aufgedruckt, die zu der zugehörigen Produkt- Webseite führen.

Da fast jeder über mehr als genug USB-Kabel verfügt, sind diese aus Platz- und ökologischen Gründen nicht enthalten. Die beiden Kartons enthalten unterschiedliche Boards. Das Entwicklungsboard PIC-IoT WA (Produkt-Nummer: EV54Y39A) basiert auf der zentralen MCU PIC24FJ128GA705. Das Entwicklungsboard AVR-IoT WA (Produkt-Nummer: EV15R70A) basiert auf einer ATmega4808-MCU aus der AVR-Reihe. Man hat also bei gleicher Funktion die Wahl zwischen einer PIC- oder einer AVR-Lösung.
In Bild 2 sieht man, dass sich nicht nur die Kartons, sondern auch die Boards stark ähneln.

Am rechten Rand der Platinen (Bild 3) sitzt eine Mikro-USB-Buchse, die das Board mit Strom versorgt und das System mit dem Debugger verbindet.

Neben dem USB-Anschluss ist der Debugger zu sehen, und darüber befindet sich eine Ladeschaltung für Lithium-Akkus. Ist ein solcher angeschlossen, kann das Board als netzunabhängige Lösung verwendet werden.
Hardware der Entwicklungsboards
Die Stromversorgung beherbergt das Li-Ion/LiPo-Lade-IC MCP73871, das vom Abwärtswandler MIC33050 mit integrierter Induktivität unterstützt wird. Diese Kombination eignet sich für eine Lithium-Akkuzelle mit einer Ladeschlussspannung von 4,2 V (wichtig bei Auswahl der Zelle); der DC/DC-Wandler bietet einen Strom von bis zu 600 mA.
Das Lade-IC fungiert als ideale Diode und verhindert einen Rückfluss des Stroms vom Akku zurück zum USB-Anschluss. Es gibt noch mehr auf der Platine, das eine genauere Betrachtung verdient: Weiter links sieht man mit dem Temperatursensor MCP9808 und dem Krypto-Co-Prozessor ATECC608A zwei ICs und einen Lichtsensor. Der Krypto-Chip kann zwar zur sicheren Kommunikation zwischen dem Board und den AWS IoT Core Services eingesetzt werden, doch ist er nicht darauf beschränkt, sondern ermöglicht sichere Kommunikation mit verschiedenen Cloud-Diensten.
In der Mitte befindet sich der zentrale Mikrocontroller. Die Variante mit dem PIC24FJ128GA705 bietet 128 KB ECC-Flash und 16 KB RAM. Bei 32 MHz Takt erreicht diese MCU 16 MIPS und bietet ein schönes Set an Peripherie sowie einen Low-Power-Modus. Bei der Variante ATmega4808, einer der neueren AVR-MCUs, stehen 48 KB Flash und 6 KB RAM zur Verfügung. Bezüglich Peripherie ähnelt er eher einer XMEGA- als einer typischen AVR-MCU. Der ATmega4808 erreicht mit einem Takt von bis zu 20 MHz maximal 20 MIPS und bietet erweiterte Peripherie sowie Energiespar-Optionen.
Am linken Platinenrand sitzt das WLAN-Modul ATWIN1510 (Bild 4).

Es unterstützt als per SPI angebundenem 2,4-GHz-Single-Band-Controller den Netzwerkzugang nach IEEE 802.11 b/g/n. Das Modul bietet mehr als nur WLAN: Man kann es quasi als Netzwerk-Coprozessor betrachten, der anspruchsvolle Aufgaben wie die Verschlüsselung des Traffics und TCP/IP-Paketverarbeitung übernimmt.
Die mittigen Buchsenreihen an beiden Seiten (Bild 5) sind mikroBus-Click-Board-Steckverbinder, mit denen man zusätzliche Sensoren und Geräte aus dem Sortiment oder mikroBus-kompatible Geräte z.B. zur 3D-Bewegungserkennung aufstecken kann.

Dreht man das Board um, dann entdeckt man, dass die verfügbaren Anschlüsse mit ihrem Namen und Pin-Nummer gekennzeichnet sind (Bild 6).

Wer an weiteren Details der Platinen wie etwa Schaltplänen interessiert ist: Microchip stellt schön gestaltete Anleitungen für beide Varianten zur Verfügung, die nicht nur viele Informationen bieten, sondern auch einen Schnellstart für die AWS-Verbindung beinhalten.
Vorinstallierte Software
Beide Boards kommen mit vorinstallierten Beispielanwendungen, die einen direkten Out-of-the-Box-Test für den AWS IoT Core unter Verwendung eines Microchip-Accounts ermöglichen. An dieser Stelle eine Warnung, die auch in der Schnellstartanleitung zu finden ist: Die mit diesem Account verschickten Daten stehen allen Zugangsberechtigten zur Verfügung. Praktisch bedeutet das hier, dass sie quasi öffentlich zugänglich sind. Die Integration der Boards ins eigene Netzwerk ist unkompliziert: Beim Anschluss des Boards an einen PC erscheint ein neues Massenspeicherlaufwerk namens CURIOSITY. Die Datei CLICK-ME.HTM im Stammverzeichnis kann in einem Browser geöffnet werden. Sie führt durch die nötigen Konfigurationsschritte. Zuerst aktualisiert man die Firmware für die MCU auf die neueste Version (Bild 7), sonst gibt es Probleme bei der Konfiguration des WLANs.

Da die Firmware des Sicherheits-Chips dadurch noch nicht aktualisiert ist, kann er noch veraltete Firmware samt veralteter oder Zertifikate enthalten. Sollten sich Probleme bei der AWS-Verbindung ergeben, werfen Sie einen Blick in den Textkasten „Was noch nicht im Manual steht“. Dort ist nachzulesen, wie man alle Komponenten des Boards auf die neueste Version aktualisiert. Für die Aktualisierung ziehen Sie die heruntergeladene Datei mit der Extension „hex“ auf das Laufwerk CURIOSITY. Anschließend wird die neue Firmware automatisch in den Flash-Speicher übertragen und die MCU neu gestartet.
Das Board in das eigene WLAN zu bekommen ist eine Sache von wenigen Klicks. die Eingabe der Zugangsdaten zur Ihrem WLAN erfolgt direkt via CLICK-ME.HTM (Bild 8).

Dabei wird eine WIFI.CFG-Datei erzeugt, die per Drag & Drop auf das Laufwerk CURIOSITY gezogen wird, um die WLAN-Zugangsdaten in der MCU zu speichern und damit eine Verbindung zum WLAN herzustellen. Ist diese Verbindung hergestellt, wird das Board versuchen, sich mit dem AWS-Service zu verbinden und dann mit der Veröffentlichung von Daten zu beginnen.
Wie geht es weiter?
Der kleine Knopf unter den Sensorwerten führt durch die nächsten Schritte. Der erste ist die Einrichtung von MPLABX (Bild 9).

Nach der Fusion von Microchip und Atmel wurde die MPLABX-Entwicklungsumgebung, die ursprünglich für die PIC-Entwicklung gedacht war, um AVR- und SAM-Chips ergänzt. Auch wenn das nicht mit dem Look & Feel von Atmel-Studio (basiert auf Visual Studio) übereinstimmt, ist es erfreulich, dass man so nicht mehr auf Windows festgelegt wird. Auch Benutzer von MacOS und Linux werden damit AVR-basierte Projekte entwickeln können – Letztere gar auf AMD64-Maschinen. Wer nur eine 32-bit-CPU zur Verfügung hat oder aber noch ein 32-bit-Betriebssystem verwendet, wird mit der neuesten Version von MPLABX Pech haben. MPLABX basiert auf der Entwicklungsumgebung Netbeans, die einst als IDE für Java begann und im Laufe der Zeit auf andere Sprachen erweitert und später von Microchip zu MPLABX modifiziert wurde. Zum Entstehungszeitpunkt dieses Artikels war die Version 5.45 aktuell, die hier auf einem Windows-Rechner verwendet wurde. Die verschiedenen Architekturen benötigen entsprechende Compiler und die Support-Dateien. Der einfache Weg hierfür ist, sie bei genügend Platz auf dem Laufwerk gleich während der Installation mitzuinstallieren. Man muss lediglich die verwendete Architektur auswählen, um die Support-Dateien zu erhalten. Bezüglich Compiler wird man nach der Installation darüber informiert, dass man ihn von der Microchip-Website holen muss. Wer den von Atmel Studio 7 gewohnten AVR-GCC-Compiler verwenden will, muss diesen manuell von der Microchip-Seite herunterladen, die Zip-Datei extrahieren und den Compiler manuell zu MPLABX hinzufügen (Bild 9). Hier wird der Pfad zum Verzeichnis angegeben, in dem die Compiler-Dateien extrahiert wurden. Er muss zum Ordner bin führen – ansonsten wird die AVR8-Toolchain nicht erkannt. Da die Beispielprojekte standardmäßig mit der XC-Compiler-Serie kompiliert werden, ist dieser Schritt ist nicht erforderlich, aber hilfreich, wenn man an die Arbeitsweise des AVR-GCC gewöhnt ist.
Entwicklungsboard AVR-IoT WA
Hier muss man die neueste AVR-IoT-WA-Anwendung herunterladen. Nach dem Herunterladen des Codes kann dieser mit MPLABX geöffnet werden (Bild 10).

Durch das angeschlossene Board bekommt man auch alle Ressourcen und Links zur Dokumentation präsentiert. Der Code wird für die nächsten Schritte des Tutorials benötigt und ermöglicht die Anpassung der Anwendung für eigene Zwecke oder aber er inspiriert zu eigenen Ideen und Entwicklungen. Bild 11 zeigt das geöffnete und erweiterte Projekt.

Der letzte Schritt des Tutorials für das AVR-Board zeigte zum Zeitpunkt meiner Experimente noch nicht die neueste Struktur des Codes. Es braucht einige Sekunden, um die wesentlichen Teile des Codes zu finden. Zur Erleichterung werden in Bild 12 die erforderlichen Code-Änderungen gezeigt, damit die grüne LED als Aktuator arbeiten kann.

Nachdem der Quellcode geändert wurde, kann er auf das AVR-Board hochgeladen werden und der LED-Status kann mit dem Schiebeschalter gesteuert werden (Bild 13).

Abgesehen von diesem kleinen Glitch funktioniert das Board wunderbar. Wenn man das Tutorial durchgearbeitet hat, stehen einem noch die Microchip IoT Developer Guides for AWS für weitere Informationen und zur Verwendung dieser Boards mit Amazons Web-Services zur Verfügung.
Entwicklungsboard PIC-IoT WA
Hier muss die PIC-IoT-WA-Anwendung heruntergeladen werden. Der Code kann in MPLABX geöffnet werden und hat die gleiche Struktur wie der Code für den AVR. Das Tutorial funktioniert fast genauso wie das des AVR – nur dass ein PIC mehr Flash, zusätzliche Peripherie und auch etwas mehr RAM bietet (Bild 14).

Man beachte, dass ein PIC im Vergleich zu AVR mehr Breakpoints in der Hardware für das Software-Debugging und Daten-Watchpoints bietet, wobei die Instruktionen pro Takt weniger effizient sind als bei AVR-MCUs. Wer den bereitgestellten Code untersuchen möchte: Der Code von main.c ist wirklich kurz:
#include "mcc_generated_files/application_manager.h"
int main(void)
{
application_init();
while (1)
{
runScheduler();
}
return 0;
}
Die Initialisierung aller Komponenten erfolgt in application_init(). Diese Funktion steckt in application_manager.c, wo die meisten höheren Funktionen zu finden sind. Der Code verwendet die Funktion runScheduler(), um alle anfallenden Aufgaben zu erledigen und zeitlich zu koordinieren. Hiervon wird die Funktion timeout_callNextCallback() aufgerufen, welche fällige Aufgaben ausführt:
inline void timeout_callNextCallback(void)
{
if (executeQueueHead == NULL)
return;
bool tempIE = (IEC0bits.T1IE == 1?1:0);
IEC0bits.T1IE = 0;
timerStruct_t *callBackTimer = executeQueueHead;
// Done, remove from list
executeQueueHead = executeQueueHead->next;
// Mark the timer as not in use
callBackTimer->next = NULL;
if(tempIE)
{
IEC0bits.T1IE = 1;
}
uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload);
// Do we have to reschedule it? If yes then add delta to absolute for reschedule
if(reschedule)
{
timeout_create(callBackTimer, reschedule);
}
}
Der Code prüft, ob etwas zur Ausführung bereit ist, und wenn nicht, kehrt er sofort zurück. Im Folgenden deaktiviert der Code zunächst für eine kurze Zeit einen Timer-Interrupt, worauf wir später eingehen werden, greift das Element, das zur Ausführung bereit ist, und ruft die Funktion auf. Der Aufruf uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload); führt die Funktion aus, und die Funktion selbst gibt die Zeitspanne zurück, in der sie erneut aufgerufen werden muss. Wenn diese Zeitspanne größer als Null ist, wird sie mit der angegebenen Zeitspanne in eine Liste von wartenden Aufgaben zurückgestellt. Der erwähnte Timer und Timer-Interrupt ist der andere Teil, der das System die Tasks ausführen lässt. In einem definierten Intervall wird die Funktion timeout_isr aus dem Timer-Interrupt heraus aufgerufen.
void timeout_isr(void)
{
timerStruct_t *next = listHead->next;
absoluteTimeofLastTimeout = listHead->absoluteTime;
lastTimerLoad = 0;
if (listHead != &dummy) {
enqueueCallback(listHead);
}
listHead = next;
startTimerAtHead();
}
Vereinfacht gesagt überprüft der Code eine Liste von Aufgaben. In der Liste können sich wirklich auszuführende Aufgaben befinden oder Dummy-Aufgaben, die nichts tun. Muss eine Aufgabe ausgeführt werden, wird sie in eine Liste mit fälligen Aufgaben eingetragen. Die nächste auf ihre Ausführung wartende Aufgabe der Liste wird geholt, und der Zeitgeber passt sein Intervall entsprechend an. Die Liste fälliger Aufgaben bearbeitet die schon erwähnte Funktion timeout_callNextCallback. Die ISR plant und bereitet die Aufgaben timer-gesteuert vor, die als Nächstes ausgeführt werden müssen. In Kombination mit der Funktion timeout_callNextCallback wird ein Zyklus erzeugt, in dem die Aufgaben verwaltet und zeitgesteuert ausgeführt werden. Wenn keine Tasks mehr ausgeführt werden müssen, könnte die MCU in den Ruhezustand versetzt werden und darauf warten, dass sie durch den Timer oder andere Events wieder geweckt wird. Dieses Konzept eignet sich nicht nur für dies Anwendung, sondern könnte auch für andere Projekte interessant sein, um Tasks mit reduziertem Stromverbrauch auszuführen.
Einen Schritt weiter
Für das AVR-IoT WA Board finden Sie hier eine Anleitung, um das Beispielprojekt mit Hilfe von MPLABX komplett neu zu erstellen. Dadurch wird man besser mit der Entwicklungsumgebung und der Programmierung vertraut. Doch Achtung: Auch wenn das alles gut funktioniert, werden einige Teile und Plug-Ins noch Verbesserungen ihrer Benutzerfreundlichkeit und Stabilität erfahren. Die Bilder 15, 16 und 17 zeigen einige Schritte auf dem Weg durch die Assistenten.



Nach der Absolvierung der Schritte der Anleitung hat man ein Projekt, das auch mit dem AVR-GCC kompiliert werden kann, falls man für diesen speziellen Compiler geschriebenen Code einbinden muss.
Bild 17 zeigt auch die Komponenten, die im AWS-Beispiel-Projekt enthalten sind, darunter CryptoAuthLibrary, WINC15XX oder Message Queue Telemetry Transport (MQTT). Sie beschäftigen sich mit den Sicherheitsfunktionen der beiden Boards. AWS IoT Core verwendet MQTT für den Datenaustausch. Wenn keine zusätzlichen Messungen vorgenommen werden, werden die Daten im Klartext ausgetauscht, so dass die Daten auf dem Weg vom Gerät oder zurück verändert werden könnten. Um das zu verhindern nutzt man MQTT Transport Layer Security (TLS) zur Verschlüsselung der Kommunikation. Auf beiden Boards befindet sich ja ein ATECC608A, der die kryptographische Arbeit von der MCU abnimmt. Zwecks Sicherheit bietet der WINC1510 TLS-verschlüsselte Kommunikation und kann dabei durch den ATECC608A unterstützt werden, damit die übertragenen Daten nicht verändert werden können. Aufgrund der Verwendung von MQTT ist man nicht auf den AWS IoT Core beschränkt. Man benötigt lediglich einen MQTT-Broker, der die Verbindungen annimmt und Daten verarbeitet.
Einfacher Einstieg
Sowohl Preis der Boards als auch ihre Software-Unterstützung sind auf gutem Niveau. Kombiniert mit den gut ausgestatteten Dokumentations- und Debugging-Möglichkeiten bieten die Boards einen einfachen Einstieg in die Welt der vernetzten Geräte, die mit beschränkter Energieaufnahme laufen. Die integrierte Ladeschaltung für Lithium-Akkus erlaubt den direkten Einsatz im Feld. Der mikroBus-Steckverbinder ermöglicht Zugriff auf eine Menge zusätzlicher Hardware für eigene Projekte. Man kann mit diesen Boards bei der bevorzugten MCU-Architektur bleiben, oder aber man nutzt die Gelegenheit, die jeweils andere MCU-Gattung samt ihren Möglichkeiten kennenzulernen. In Kombination mit dem Onboard-Debugger und der plattformübergreifenden Lösung für alle drei wichtigen Betriebssysteme bieten die Boards eine mehr als vollständige Lösung.
Was noch nicht im Manual steht
Es kann sein, dass beim gelieferten Board mit älterer Firmware die Daten für den ATECC608A veraltet sind. Dann kann sich das Board zwar problemlos mit Ihrem WLAN verbinden, aber keine Verbindung zum AWS IoT Core herstellen. Sie können dann nicht die Schritte der Anleitung nachvollziehen. Um die neueste Firmware auch für den ATECC608A und den Onboard-Debugger aufzuspielen, kann man das IoT Provisioning Tool verwenden. Es läuft auf allen drei wichtigen Betriebssystemen als Kommandozeilen-Anwendung. Hierzu entpackt man die heruntergeladene Datei, und startet das Terminal (MacOS und Linux) bzw. eine Befehlszeile (cmd.exe bei Windows). Für Windows lautet der Befehl iotprovision-bin.exe -c aws -m sandbox. Anschließend ist das Board „up to date“ und alle erforderlichen Zertifikate sind vorhanden. Für die Verwendung von Google-Services sollte man sich das Video-Tutorial von Microchip zum Wechsel des Cloud-Providers anschauen.
Diskussion (9 Kommentare)
Alexander vor 3 Jahren
AVR vor 3 Jahren
Alexander vor 3 Jahren
So ein Controller Platinchen mit was auch immer dran und im Internet unter falscher Kontrolle lässt schnell die Erfassung wann jemand Zuhause ist oder nicht zu. Das recht bereits um eine Gefahr für die ganze Familie zu sein. Mir ist Grundsätzlich bei allen Daten wichtig das ich die Kontrolle darüber habe. Bei meinen Software Entwicklungen weil die mein Kapital sind und zum Teil sehr viel besser als das was die Industrie bieten kann ganz besonders.
Wenn ein Kind Rechtschreibfehler macht ist das für alle ein Weltuntergang. Wenn das Kind mit einem alten Handy herumläuft zu dem es schon seit Jahren keine Updates mehr gibt und das es ermöglicht das Kind 24 Stunden Online zu verfolgen interessiert das niemanden. Argument ist ja nur ein Kind was sollen die mit den Daten so wichtig sind wir nicht. Klar logisch es gab ja noch nie Kriminelle die Interesse an Kindern hatten in Deutschland. Wenn Eltern was an ihren Kindern liegt geben sie denen die neuen Geräte und benutzen selbst die alten. Wobei halt tote Eltern auch kein Brüller sind. Wird nie passieren ist mir schon klar aber die Eltern müssen sich dann auch den Vorwurf gefallen lassen das der Nachwuchs nur niedere Priorität hat.
IT Sicherheit muss für jeden genauso wichtig werden wie die Rechtschreibung. Nur das die Rechtschreibung so lange man erkennen kann was jemand geschrieben hat wirklich keine Bedeutung hat. Dank des Umstandes das Menschen im Gegensatz zu dem lächerlichen Industriellen KI Schrott herausragende Fähigkeiten bei der Fehlertoleranz haben.
AVR vor 3 Jahren
Sonst besteht die Gefahr, das Thema massiv zu übertreiben und sich das Leben schwerer zu machen als nötig. Das ist schnell passiert, wenn im Feuereifer bester Absichten Theorie immer gleich mit der Praxis gleichgesetzt wird. Letzten Endes muß aber jeder für sich entscheiden, mit welchem Sicherheitsaufwand er sich wohlfühlt. Regulatorische Übertreibung, Risikoscheu, Sicherheitswahn und Datenschutzparanoia scheint mir aber in direktem Zusammenhang mit immer zäheren Entscheidungsprozessen, immer komplizierteren Verfahren und der Teuerung in unserem Land zu stehen.
Jan Hauß vor 3 Jahren
Wenn dann der (Daten-/Onlinebanking-/Haus-) Einbruch stattgefunden hat, nachdem all dieses Sensorchen gegen einen verwendet wurden - und die digitalen Spuren sehr gründlich gelöscht worden sind - braucht man keine Bedenken mehr...
Das Problem ist, dass die Mehrzahl der Firmen und Privatpersonen Datensparsamkeit und IT-Security gut findet - solange es sie kein Geld - und keine Bequemlichkeit kostet.
Man muss kein Prophet sein um die absehbaren Folgen vorherzusehen. (Tipp: NIMDA war ein laues Lüftchen dagegen.)
Die richtige, teure und aufwändige Antwort auf diese Probleme heißt schon bei der Anschaffung nicht Quelloffener Haus-IT "Nein" sagen zu können. Produkte und Netzwerke zu zu klassifizieren, ggf. zu trennen und Notfallpläne auszuarbeiten. (In jedem RZ/DC seit >40 Jahren Standard). Nur dann hat man "Bedenken first".
Das sich das Lieschen Müller mit der "Fritte" an der Wand, der M$-Wanze unter den Fingern und dem Apfelabhörgerät am Ohr nicht macht, ist klar. Die Folgen (nicht nur für Lieschen - sondern auch für die Kinder, den Enkel ...) irgendwann auch!
Ein halbwegs sauberes Hausnetz haben m.E. <0,1% der Haushalte. Kein Zeichen für die korrupte Politik etwas zu tun.
Immer mehr Produkte werden in m.E. in unverantwortlicher Weise, unnötig als Cloud gebundene Bots programmiert. Der Mehrwert für den Kunden ist häufig nicht erkennbar. Nur der Betreiber versucht mit den Bewegungsdaten der Kunden, um die DSGVO herum, einen Reibach zu machen ("Datenreichtum" "Daten sind das neue Öl"). Widerlich, das das noch legal ist. Im Zweifelsfall haftet der Clouddatensammler nämlich nicht für die Folgen - seines gierigen - und allzu häufig dilettantischen Vorgehens.
AVR vor 3 Jahren
Die Medien sind ja auch voll davon ;-)
Leute kommt zurück auf den Boden der Tatsachen! Technik wird zwar nie 100% sicher sein (wer das sucht soll drauf verzichten) aber sie kann praktisch hinreichend sicher betrieben werden, wie Milliarden Einsatzfälle täglich beweisen.
Jan Hauß vor 3 Jahren
Wenn jemand anderes als Du deine Geräte - zu seinem eigenen Vorteil hin - kontrolliert muss das nicht heißen, das Du das mitbekommst, wenn Du nicht danach suchst.
Ich habe eine Kabelanschluss in Internet und nutze iptables rules zur Absicherung. (Nach Durchsicht der Logfiles - stellte sich heraus, dass das keine Spielerei war. >10 attack scan / h).
Auch der umgekehrte Weg des Logging des (ungefragt, ungewollten) Datenflusses ins Internet kann ich jedem sehr ans Herz legen.
Die meisten "smart" irgendwas Heinzelmännchen sind dermaßen Dateninkontinet, dass dem einen oder anderen ein PI-hole den Weg weisen muss. Dass dieser convenience Elektromüll nicht in ein Netzwerk mit Geräten gehört, auf dem personenbezogen Daten liegen versteht sich von selbst.
Aber wer nichts zu verlieren - oder zu verbergen hat - der schreckt auch davor nicht zurück.
Schau mal bei Shodan rein - 7-8stellige tägliche Problemfälle sind dort die Regel. (7links IP-Cam etc., etc., etc. )
Martin Schönegg vor 3 Jahren
Ich möchte gar nicht wissen, wie viele Geräte im Netz - einfach, weil sich keiner drum schert - zum Sicherheitsrisiko im Netz werden. Millionen von OTA-flashbaren IoT-Devices, wie z.B. Sonof und andere ESP-basierte Steckdosen können doch nichts Schlimmes machen, oder? Und was ist, wenn jemand die übernimmt und einen Code ergänzt, der sie zum willfährigen Helfer für DDoS- Angriffe nutzt? Dafür braucht es kaum Codezeilen. Die finden unauffällig Platz in derlei Prozessoren (wer an Verschwörungstheorien glaubt, der geht eh davon aus, dass die Chinesen das bereits eingebaut haben).
Es geht längst nicht mehr nur darum, einem End-Nutzer etwas Böses zu wollen. Aber selbst da gibt es genügend kreative Köpfe, die sich Ungemach auszudenken vermögen, an die wir heute noch nicht im Traum denken.
Es ist schon eine Weile her, da hat meine Oma fast einen Wutausbruch bekommen, genau wegen solchen Sprüchen: Bei den Blockwarten in Ihrer frühen Jugend hatte man auch gesagt: Lebe anständig, dann ist es egal, wer zuschaut. Jahre später sah sie das mit einer doch sehr geänderten Sicht. Auch so mancher ehemalige DDR-Bürger hatte sich nach der Wende bei der Stasi-Akteneinsicht ungläubig die Augen gerieben...
Bleibt meinetwegen faul und bequem in Bezug auf Facebook, Google und Co, aber bitte haltet das Netz sauber!
Martin
AVR vor 3 Jahren