Sehr interessant, beantwortet nur meine Frage nicht.

Ich finde schon... wäre herauszufinden wie RAIM reagiert, wenn es die Wahl zwischen z.B. 5 richtigen Satelliten und plötzlich 20 Falschen hat? Wie sieht der Algorithmus aus? Gibt's ein Overflow wenn plötzlich 100 Satelliten angeboten werden? Was passiert bei 65.535+1 oder 2.147.483.647+1 ?

Nein. Es ist eine Sache, ein Signal zu stören. Wird das vom Empfänger und seiner Software aufgedeckt, sind die Konsequenzen recht begrenzt.

Wird das Signal dagegen (lokal) ersetzt, um damit z.B. ein Telefon oder eine Drohne zu manipulieren, können sich schon erheblich gravierende Folgen ergeben.

Aber erst, wenn das manipulierte Signal auch von sich schnell und großräumig bewegenden Empfängern, die dazu noch halbwegs paranoid sind und unaufhörlich Qualität und Glaubwürdigkeit prüfen, als echt erkannt wird, kann es zu wirklich ernsthaften, dann aber schnell katastrophalen Konsequenzen führen.

Daher ist eine genaue Unterschiedung in dieser Diskussion wichtig.

P.S.:{Auch ein ILS lässt sich ohne großen Aufwand stören, allerdings führt das schnell zur Abschaltung des Signals durch die Bodenstation. Auch das kann man sicher umgehen, aber vermutlich ist das dann schon eine wesentlich komplexere Aufgabe.}

Full ACK - lass es mich doch ein wenig auf die Spitze bringen ;-)

Ein Veto jedoch was den Overhead anbetrifft. Der wird höher liegen ja, aber auch nicht so hoch, daß es signal- und laufzeittechnisch relevant sein dürfte. Ich habe auf die Schnelle diesen Artikel aus 2010 gefunden (noch mit dem unsicheren SHA1) der dieses stützt. Und gzippen könnte man alles auch noch.

https://netsekure.org/2010/03/tls-overhead/

Wie auch immer. Ich denke wir sind uns einig, daß da auf jeden Fall mehr Sicherheit ins System rein sollte.

Ich bin mir nicht sicher ob ich verstanden habe was Du meinst. TLS ist ein Handshake-Verfahren, aber genau das ist ja nicht machbar.

Meinst Du den Overhead der RSA (o.ä. asymmetrisches Verfahren) Pakete? Die werden hier mit 130 Byte angegeben. Heißt 1024 Bit, ist also schon unsicher. 2048 Bit wäre dann 256 Byte, was ganz ordentlich ist und in 10 Jahren wahrscheinlich ebenfalls unsicher...

Was willst Du gzippen? Die verschlüsselten Pakete? Das bringt gar nichts; die haben maximale Entropie.

Wenn die Antenne die Richtung des Signals ermitteln könnte (weiß ich nicht; weiß das jemand hier?) dann könnte man recht einfach alle vom Boden kommenden Signale ausschließen und fordern, daß die Signale aus mindestens 3 Verschiedenen Richtungen stammen müssen. Das würde schon die Hürden so hoch setzen, daß es nur Staaten oder Großkonzerne machen könnten.

Wir haben im GPS eine Datenrate von 50Bit/s. Für ein gesamten Paket werden 12,5 Minuten benötigt, da will man kein RSA-Signatur mitanhängen.

50Bit/s * 12,5Minuten = 4687,5 Byte

Auch zur Frage was die RAIM macht wenn es x Satelliten gibt.

Für GPS-Satelliten sind 37 verschiedene Codes definiert und für SBAS sind es 19 verschiedne Codes spezifiziert.

Mehr unterschiedliche Satelliten kann ein GPS-Empfänger nicht empfangen.

Ich bin mir nicht sicher ob ich verstanden habe was Du meinst. TLS ist ein Handshake-Verfahren, aber genau das ist ja nicht machbar.

Gut möglich, daß ich da auch was durcheinander bringe, also korrigiere mich bitte, wenn ich falsch liege: Wollte man den Handshake nicht mit Zero-Roundtrips in TLS 1.3 genau wegen der Latenzen und Geschwindigkeit eleminieren?

Was willst Du gzippen? Die verschlüsselten Pakete? Das bringt gar nichts; die haben maximale Entropie.

Mmm okay, hatte jetzt mod_gzip aus dem Apache im Hinterkopf, der HTTPS Traffic auch zippt...

Richard, es geht doch noch einfacher: ich arbeite nur mit Auffanglinien, Atlantik im Westen, Alpen im Süden und so. Leider gibts den Eisernen Vorhang im Osten ja nicht mehr, da muss ich mir dann mal was einfallen lassen :-)

P.S.: in meiner mündlichen PPL Prüfung mussten wir noch die deutschen Mittelgebirge und Flüsse namentlich nennen können!

Wir haben im GPS eine Datenrate von 50Bit/s.

Okay bei 50 Bit/s im Band hast mich überzeugt... dann geht's nur mit mehreren Bändern womit wir dann im militärischen GPS wären oder?

Für GPS-Satelliten sind 37 verschiedene Codes definiert und für SBAS sind es 19 verschiedne Codes spezifiziert.

Okay, das beantwortet den Gedanken nicht was RAIM genau macht wenn zwischen 5-6 richtige arbeitenden Satelliten plötzlich 20 Falsche hinzu kommen? Oder wenn mit anderen Mitteln oder Methoden ein Pen-Test auf die ganzen Geräte gemacht wird.

Das ganz am Anfang genannte Beispiel des Audits der Homeland-Security in Erinnerung bringend: Wenn Security Experten binnen 2 Tagen remote eine 757 "kapern" konnten und die Findings unter verschluß gehalten werden, ist das nicht gerade vertrauensfördernd. Security through obscurity.

Ein Paper zu diesem Thema habe ich gerade gefunden:

https://www.cl.cam.ac.uk/~mgk25/gps-auth.pdf

Das ist dch was Greifbares! Vielen Dank für das Paper:

Vielleicht bin ich ja zu sehr Idealist wenn ich denke "Hey, die schöne GPS Burg, die unsere Wirtschaft, Luftfahrt und ganzes Zusammenleben schützt, ist auf Sand gebaut. Lasst uns doch was Besseres bauen!" - Statt dessen wird empfohlen "Nö, wir verbieten dann einfach, daß es regnet" was die Verfügbarkeit von Tools, Simulatoren & Co anbetrifft.

Also wenn man mal ein paar Minuten mit der Materie beschäftigt, findet man schnell heraus, daß sowohl Betreiber der GNSS-Systeme, wie auch Vertreter der Anwender und Regulatoren das Thema durchaus auf dem Schirm haben. RAIM ist ja nicht das einzige Mittel, fehlerhafte Signale (ob nun gezielt gefälscht oder defekt ist fast egal) zu identifizieren. Je nach Anflug gibt es ja bereits SBAS oder GBAS im Betrieb, ABAS mit INS-Kopplung, also AAIM (oder per Pilot, der ab und an auf den Schnapskompass schaut) gibt es auch bereits. Oder DGNSS. Ein Backbone über DME/DME bleibt wohl ebenfalls bestehen, sowie die Beobachtung durch ATC. Es gibt ganze Konferenzen und halbe Büchereien, die sich mit dem Thema Anti-spoofing beschäftigen.

Ich denke nicht, daß Du "zu sehr Idealist" bist...

Wenn Security Experten binnen 2 Tagen remote eine 757 "kapern" konnten

Was genau haben die denn "gekapert"? Das FMS? Die FADECs? Oder doch nur das Entertainment-System? Und wie weit waren sie dabei vom Objekt entfernt?

Das FMS. Von Honeywell in diesem Fall. Rein sind sie via ACARS.

Es ist Ihnen gelungen Code im System dauerhaft unterzubringen und zu verstecken. Dadurch konnten sie mit dem FMS kommunizieren, Flugpläne und Datenbanken manipulieren, Kommandos ausführen und Schadcode nachladen (https://conference.hitb.org/hitbsecconf2013ams/materials/D1T1%20-%20Hugo%20Teso%20-%20Aircraft%20Hacking%20-%20Practical%20Aero%20Series.pdf).

auch Dir Danke für die Folie... au Backe beim ersten Überfliegen... da sieht man einmal wozu eBay und XPlane für alles so gut sind ;-)

Das FMS. Von Honeywell in diesem Fall. Rein sind sie via ACARS.

Und wo ist da jetzt die Referenz zu der realen B757 aus dem zuvor geposteten Link? In den Folien sehe ich nur eine Laborumgebung mit bei EBay gekauften FMCs.

Hallo Andreas, bei meiner schriftlichen Theorieprüfung (handschriftlich ohne ankreuzeln von vorgegebenen Antworten) mussten wir noch Skizzen von der Gebirgen und Mittelgebirgen sowie der Fußsysteme Deutschlands zeichnen.

Bei meiner Fliegerei in Afrika vor GPS-Zeiten ohne VOR Stationen, max. NDB haben wir auch nach solchen großzügigen Auffanglinien navigiert und sind immer angekomme

in der Tat erkenne ich auch keine Referenz zum DHS Hack... aber... das was ich aus einer zweiten Slide von ihm erkennen kann (Präsentation bei Vereinigung Cockpit aus 2014) ist folgendes:

Sein Angriffsvektor sind LSP (loadable software parts). Die AMI Fleet Management Software (bekommt er frei per Post von ARINC zugeschickt?!?!? Und weil's so schön einfach war, bitte zwei Exemplare zusenden).

Über das Teledyne Wireless Ground Link System kann er dann all die Systeme manipulieren. Die Payload wird an verfügbaren Simulatoren erstellt. Die Software ist identisch. Mir sträuben sich die Haare, was die Sicherheit im RTOS da aussieht (alle Prozesse laufen als root in Kernel Threads).

Mangels Flugzeug hat er einen FMC in eine Drohne verpflanzt und die Payload damit erfolgreich getestet.

Daß er also über ACARS rein kommt, das halte ich für eher unwahrscheinlich. Es wird wohl WLAN oder 3G/4G sein. Da ich wette, daß die Remote-Anmeldung an so einer Konsole oder schlimmstenfalls einfach nur der Upload via FTP (im Worst Case, SFTP dürfte bestimmt viel zu neu sein *hust*) und die Authentifizerung bestimmt nur mit User/Passwort erfolgt (2-Faktor TOTP/ RFC 6238 dürften vermutlich ebenfalls unbekannt sein) sieht es technisch betrachtet, nach einem einfachen Ziel aus.

P.S.: in meiner mündlichen PPL Prüfung mussten wir noch.......

war die "schriftliche" so grenzwertig ?

Weder das DHS noch eventuell involvierte Dritte haben ein Interesse, zu Protokoll zu geben, was genau wem gelungen ist. Da bekommt man keine „Referenzen“. Die Folien sind im Kontext einer ganze Reihe von Arbeiten mit verschiedenen Angriffsvektoren und Exploits zu sehen. Öffentlich bekannt scheint mir relativ wenig zu sein. Der Vortrag von Hugo Teso ist der interessanteste und konkreteste, den ich bislang gefunden habe.

Und ja, das Ganze stand vernünftigerweise(!) in einer Laborumgebung statt. Das finde ich aber nicht unbedingt beruhigend. Das Ergebnis bleibt: Mittels ACARS ist es ihm laut eigener Aussage gelungen, sich dauerhaft in mehr als einem FMS (er hat Original-Code der Hersteller genutzt) einzunisten.

Nur damit das Szenario wirklich klar ist: Er hat sich per FR24 & Co. Targets rausgesucht, die er weltweit mittels SITA/ARINC-Services angreifen konnte. Alternativ konnte er mittels SDR innerhalb der eigenen Reichweite Flugzeuge angreifen. Und mein Lieblingsszenario „Air-to-Air“: Er hat eine Payload entwickelt, mit der er von bereits gekaperten FMS weitere Systeme angreifen konnte.

Welche Exploits er dazu genutzt hat und welche Flugzeugsysteme von dort aus für ihn angreifbar waren hat er nicht veröffentlicht. Es wäre für ihn auch ein schlechtes Geschäft, seine (potenziellen) Kunden in die Pfanne zu hauen. Die Bild-Spur zu den Folien ist hier und enthält weitergehende Informationen: https://youtu.be/wk1jIKQvMx8

Ach, weißte, Erwin, mein großes Latinum habe ich auch nur, weil ich vor der Notenbesprechung der gesamten Lateinklasse eine Runde Cola versprochen hatte. Und zum Abi meinte meine Englischlehrerin, ich würde niemals in meinem Leben richtig Englisch zu sprechen.

... auch so bist du mir lieb und wert !

deinen humor weiß ich zu schätzen.

....vermutlich aber eine Eins in BWL :-)

Guten Morgen,

nach einem schönen Flugsonntag ereilt einem der graue Montag morgen wieder...

Diese Poliitk des "unter Verschluß" haltens von Vulnerabilities ist aber genau das, was NICHT hilft. Hier täte die Luftfahrtindustrie sehr gut daran aus den Erfahrungen der digitalen Welt zu lernen. Stichwort: Full Disclosure. Fehler gehören nach einer Karenzzeit z.B. 90 Tagen an die Öffentlichkeit. Länger sollte es auch nicht sein sonst nutzen Marktteilnehmer es schamlos aus.

1. Systeme müssen offen und für jedermann zugänglich und nutzbar sein - gerade die für sicherheitsrelevante, kritische Bereiche wo Menschenleben dran hängen. Denn wenn eine Software, ein Update- oder Verschlüsselungs-Mechanismus wirklich sicher sind, dann kann man diese auch bedenkenlos veröffentlichen. Kerckhoff wurde ja oben schon genannt.

2. Jedes remote oder mit einem Netzanschluß ausgestattete Gerät muß verbindlich ein Verfallsdatum aufgedruckt bekommen, damit gewisenhafte Hersteller die Chance erhalten, Software zu fixen und die schwarzen Schafe der Branche identifiziert werden können, die Ihren Dreck lieber billig offshore oder von Studenten machen lassen.

3. Förderung des Einsatzes von Open Source Software oder noch besser: Förderung der einzelnen Projekte selbst, damit die Basis für ein Peer Review möglichst breit ist. Hinter vielen weltweit gebrauchten und wichtigen Komponenten stecken leider viel zu wenige Köpfe.

Aber der Druck einer auf Herrschaftswissen angewiesenen Branche, inkompetente und die Relevanz des Ganzen nicht erfassende Funktionäre und schlicht desinteressierte und noch weniger kompetente Politiker haben alle gemeinsam kein Interesse an einer Verbesserung des Status quo... bis die ersten Script Kiddies mit Equpiment von wenigen 100 USD La Guardia oder ein paar SIDs oder STARs ein wenig nährer an Ground Zero rücken.

Mir wird wirklich Angst und Bange, wenn ich solche Meldungen im Ticker lese, wo ich mich an den Kopf packe und frage, ob die BWL- und Marketing-Fuzzis überhaupt einen Schimmer davon haben, was die da für digitale Sandburgen bauen?

Der Rant am Montag morgen... das tut gerade gut... :-)

Heute rühren wir aber alle möglichen Zutaten in einen einzigen Topf, was? Noch Restalkohol von Sylvester im Kopf ;-)

Diese Poliitk des "unter Verschluß" haltens von Vulnerabilities ist aber genau das, was NICHT hilft. Hier täte die Luftfahrtindustrie sehr gut daran aus den Erfahrungen der digitalen Welt zu lernen. Stichwort: Full Disclosure. Fehler gehören nach einer Karenzzeit z.B. 90 Tagen an die Öffentlichkeit. Länger sollte es auch nicht sein sonst nutzen Marktteilnehmer es schamlos aus.

Ich weiß nicht, wie gut Du die Software-Entwicklung im (wirklich) großen Stil kennst, aber 90 Tage halte ich für knapp. 6 Monate allerdings auch wieder für zu lang...
Im Grundsatz sind wir uns einig: Die Industrie muss hier Verfahren haben, mit solchen bekannt gewordenen Lücken zügig und sachgerecht umzugehen.
Aber bevor mir jemand mit "agile Methoden" oder "DevOps" kommt. Die betroffenen Microcodes und Betriebssysteme und vor allem deren Entwicklungsprozesse/-verfahren mit den beteiligten Stellen in den Unternehmen sind über (teilweise) Jahrzehnte "gereift" und lassen sich - meiner bescheidenen Erfahrung nach - zwar auf "agil" und "DevOps" umstellen, aber nur unter erheblichem Aufwand und nicht einfach so per Ansage der Chefs.

1. Systeme müssen offen und für jedermann zugänglich und nutzbar sein - gerade die für sicherheitsrelevante, kritische Bereiche wo Menschenleben dran hängen. Denn wenn eine Software, ein Update- oder Verschlüsselungs-Mechanismus wirklich sicher sind, dann kann man diese auch bedenkenlos veröffentlichen. Kerckhoff wurde ja oben schon genannt.

Spannende Forderung. Aber wie willst Du dann noch die wirtschaftliche Nutzung von selbst programmierten Anwendungen ermöglichen? Sprich: Wie soll ein Unternehmen sicherheitskritische Software überhaupt noch verkaufen, wenn Du die Zugänglichkeit für jedermann forderst? Und welchen Anreiz hätte dann ein Unternehmen, sich überhaupt noch mit sicherheitsrelevanter Software zu befassen? Alles unter staatlicher Kontrolle? Dann wird's besser?

2. Jedes remote oder mit einem Netzanschluß ausgestattete Gerät muß verbindlich ein Verfallsdatum aufgedruckt bekommen, damit gewisenhafte Hersteller die Chance erhalten, Software zu fixen und die schwarzen Schafe der Branche identifiziert werden können, die Ihren Dreck lieber billig offshore oder von Studenten machen lassen.

Cool. Und mit einem neu installierten Patch, der die Nutzbarkeit verlängert, bekommt dann jeder Anwender noch einen neuen Aufkleber mit neuem "Haltbarkeitsdatum" zum Drüberkleben zugeschickt? Echt jetzt?
Oder kommt das Ordnungsamt und prüft die termingerechte Entsorgung der Geräte?
Ja, auch ich nutze einen Router am Netz und habe dort diverse Geräte angeschlossen. Ja, ich weiß, was passieren kann, wenn jemand meinen Router hackt oder lahmlegt.
Und nein, ich habe keine smarten Türöffner, Heizungsanlage oder Fenstersteuerung. Wenn mir jemand meinen Router hackt, dann ist das so. Zum Glück bin ich mit meiner Infrastruktur anscheinend so uninteressant, dass bisher keiner meiner Rechner von irgendeinem Virus oder anderer Malware befallen wurde. Oder aber meine Familie und ich befolgen die einfachen Regeln, die man immer wieder in etwas besser informierten Medien liest (wenn man davon absieht, dass ich einmal mit etwas zu dickem Finger auf meinem Android-Smartphone auf einen kleinen unscheinbaren "hier abonnieren"-Knopf gekommen bin. Hat mich 3,99 gekostet und bin ich auch losgeworden. Lehrgeld), und die helfen dann auch. Ein Restrisiko bleibt, natürlich, aber drum werde ich meine Infrastruktur nicht abschalten.

3. Förderung des Einsatzes von Open Source Software oder noch besser: Förderung der einzelnen Projekte selbst, damit die Basis für ein Peer Review möglichst breit ist. Hinter vielen weltweit gebrauchten und wichtigen Komponenten stecken leider viel zu wenige Köpfe.

Globalgalaktische Imponierforderung. Klingt erst mal toll, aber die Umsetzbarkeit im Einzelnen wird schon etwas schwieriger: Wer soll fördern? Wer entscheidet, was gefördert wird bzw. wann eine Förderung eingestellt wird? Nach welchen Kriterien? Wie viel Geld soll zur Verfügung stehen, und wo kommt das genau noch mal her? Und wer kriegt das Geld dann eigentlich, wenn es sich um Open Source handelt. Die Mailingliste der Linux-Kernel-Entwickler ist meines Wissens recht lang...Bekommt dann jeder gleichviel, oder anhand seiner beigesteuerten Lines of Code? Wer zählt die?...Verdammt viele offene Fragen...

Aber der Druck einer auf Herrschaftswissen angewiesenen Branche

So ziemlich jede produzierende Industrie ist auf "Herrschaftswissen" angewiesen. Maschinenbau, Spielzeug, Nahrungsmittel, .... Manches davon patentiert, anderes wiederum nur im Detail (spezielle Materialien, spezielle Verfahren, spezielle Baupläne/Designs, spezielle Rezepte...), und vieles davon sicherheitsrelevant oder gesundheitsrelevant. Wo ist das Problem hier? Meines Erachtens ist das ein Teil der Geschichte von "Angebot und Nachfrage"

, inkompetente und die Relevanz des Ganzen nicht erfassende Funktionäre

Welche? Verbände/Vereine? Meinst Du ICAO, IATA und Konsorten?

und schlicht desinteressierte und noch weniger kompetente Politiker

Du hast Deinem für Deinen Wahlkreis zuständigen Bundestagsabgeordneten schon eine entsprechende Information geschickt? Mit welcher Reaktion? Ich habe so was (zu einem anderen Thema) schon mal gemacht, und es kamen interessierte und sachliche Rückfragen, woraus sich zumindest im Rahmen einer öffentlichen Veranstaltung noch ein kurzes Gespräch entwickelt hat.
Kleine Schritte, aber Schritte...

haben alle gemeinsam kein Interesse an einer Verbesserung des Status quo...

Pauschale Behauptungen sind immer richtig...oder so...

bis die ersten Script Kiddies mit Equpiment von wenigen 100 USD La Guardia oder ein paar SIDs oder STARs ein wenig nährer an Ground Zero rücken.

Ob es so einfach sein wird, sei noch mal dahin gestellt. Die hier im Thread verlinkten Folien haben mir noch nicht eindeutig nachgewiesen, dass jemand aktiv ins FMS eines im Einsatz befindlichen Fliegers unentdeckt entweder eine falsche Datenbasis oder falsche Anweisungen eingeschleust hat. Vieles deutet natürlich in die Richtung, dass das grundsätzlich klappen könnte...Aber vielleicht muss erst wirklich was passieren, bevor weitere Regeln und Kontrollen eingeführt werden. Traurig genug wäre es. Das hat das Finanzwesen aber auch (mehrfach) hinter sich und ist trotz Basel II, III, IFRS9, MARisk, etc. immer noch nicht frei von "Risiken und Nebenwirkungen".

Mir wird wirklich Angst und Bange, wenn ich solche Meldungen im Ticker lese, wo ich mich an den Kopf packe und frage, ob die BWL- und Marketing-Fuzzis überhaupt einen Schimmer davon haben, was die da für digitale Sandburgen bauen?

Und noch eine neue Zutat in den Rant-Eintopf. Kannst Du beurteilen, ob hinter dem (offensichtlichen) Marketing-Gefasel aus dieser Pressemeldung mehr steckt? Und ob das Hand und Fuß hat? Wie auch immer, mit deiner "Sicherheitsphobie" von oben hat das erst mal nix zu tun. Wenn Eurowings sich digitalisieren möchte, sollen sie das doch tun. Ob sie über ihre neue Software dann besser Tickets verkaufen, Flüge planen/auslasten und Personal verwalten können oder nicht, wird sich dann zeigen.
So lange die nicht in die Software im Cockpit eingreifen, ist doch alles gut...

So, jetzt haben wir für die nächsten Beiträge wieder Futter ;-)

Frohes Neues Jahr

Olaf

...bei Dir sind alle anderen immer unfaehig, Fuzzies, unwillig, uninteressiert, waehrend Du offenbar den Eindruck hast, die Weisheit fuer Dich gepachtet zu haben. Wie kommt man zu so einem Selbst- und Weltbild?

Dunning-Kruger-Effekt? Und zur Sache: Es ist ein grosser Vorteil der Digitalisierung, dass sie sich auf Grund ihrer Geschwindigkeit einer Regulierung weitgehend entzieht. Ja, das bringt Nachteile und Gefahren (anzunehmen, dass sich dessen keiner bewusst sei, ist nicht haltbar, das Netz ist doch voll davon und wie Du ja zeigst, beschaeftigen sich auch in der Peripherie der digitalen Welt taetige Entwickler mit diesen Themen - so wie ganz viele andere Menschen auch), es bringt vor allem aber auch Innovationen hervor, die offenbar von den Menschen begruesst und angenommen werden.

Danke, geht mir ganz genau so, Erwin. Auch schätze ich Deine Geradlinigkeit. Mit Dir (als Du noch Dein Gewerbe ausübtest) könnte ich mir sehr gut vorstellen, einfach per Handschlag perfekt zu arbeiten. Sowas geht den nachwachsenden Generationen leider immer mehr verloren.