Login: 
Passwort: 
Neuanmeldung 
Passwort vergessen



Das neue Heft erscheint am 30. März
War früher alles besser?
Frühjahrsflug in die Normandie
EDNY: Slot-Frust und Datenleck
Triebwerksausfall kurz nach dem Start
Der kleine QRH-Bausatz
Unfall: Wer zu oft warnt ...
Engagierter Journalismus aus Sicht des eigenen Cockpits
Engagierter Journalismus aus Sicht des eigenen Cockpits
Sortieren nach:  Datum - neue zuerst |  Datum - alte zuerst |  Bewertung

47 Beiträge Seite 1 von 2

 1 2 
 

5. Januar 2018: Von John Martens an ch ess

Immer wieder findet sich wieder jemand, meist mit noch geringer Anwesenheitsdauer hier, der versucht, genau die Teilnehmer mit rationalen Argumenten zu überzeugen, die bereits wiederholt deutlich gemacht haben, dass sie sich in ihrer Meinung durch Fakten in keiner Weise stören oder gar überzeugen lassen.

jep, das wird mir auch langsam klar.

Der Unterhaltungswert sinkt, obwohl man aus Beiträgen, mit denen sich wieder jemand an einemsolchen Meinungsfels abarbeitet, durchaus manches lernen kann...

5. Januar 2018: Von Wolff E. an John Martens

@John, macht ja nix, ich bin am Anfang auch auf unseren "Superschlauen" eingegangen. Musste wie viele einsehen, das es Zeitverschwendung ist. Einfach überlesen, lohnt meist nicht, was er schreibt. Zumal, wenn man das GPS verschlüsseln würde, was bringt das? Nichts, da die Empfänger ja das Signal irgendwie entschlüsseln müssten und dazu den Key benötigen würden. Erst eine 2-Way Kommunikation mit User/Password würde es sicherer machen. Und das ist im GPS nicht vorgesehen und würde das System auch völlig überfordern bzw. die Sender in den Empfängern brauchen auch deutlich mehr Strom beim senden als beim empfangen.

5. Januar 2018: Von Chris _____ an Wolff E.

"Zumal, wenn man das GPS verschlüsseln würde, was bringt das? Nichts, da die Empfänger ja das Signal irgendwie entschlüsseln müssten und dazu den Key benötigen würden. Erst eine 2-Way Kommunikation mit User/Password würde es sicherer machen"

Stichwort asymmetrische Verschlüsselung / kryptographische Signatur.

Und hört einfach mal mit dem Bashing gegen TJ auf. Verdammt schlechter Stil.

5. Januar 2018: Von Tee Jay an Chris _____

Danke, vollkommen richtiges Stichwort. Interessanterweise sind symmetrische Verfahren sowas von 70er Jahre... genauso wie GPS... muss gerade schmunzeln...

In den letzten Jahrzehnten hat man mit TLS genau die gleichen Probleme durchlebt... wenn der übertragene GPS Inhalt nur mit mathematisch sicheren Algorithmen abgesichert wäre, könnte auch nichts gespooft werden.

5. Januar 2018: Von John Martens an Wolff E.

@John, macht ja nix, ich bin am Anfang auch auf unseren "Superschlauen" eingegangen. Musste wie viele einsehen, das es Zeitverschwendung ist. Einfach überlesen, lohnt meist nicht, was er schreibt. Zumal, wenn man das GPS verschlüsseln würde, was bringt das? Nichts, da die Empfänger ja das Signal irgendwie entschlüsseln müssten und dazu den Key benötigen würden. Erst eine 2-Way Kommunikation mit User/Password würde es sicherer machen. Und das ist im GPS nicht vorgesehen und würde das System auch völlig überfordern bzw. die Sender in den Empfängern brauchen auch deutlich mehr Strom beim senden als beim empfangen.

Jep... Das disskutieren macht ja eigentlich Spaß... Aber so bringt es wenig... Es gibt vermulich Möglichkeiten eine relativ sichere Einweg Verschlüsselung zu machen wie z.B. Sky das macht...

5. Januar 2018: Von Richard Georg an Wolff E. Bewertung: +1.00 [1]

Also >>

Ade GPS

Zurück zu Papierkarte, Navigationsbesteck und Uhr.

Auch ade von NDB, VOR und ILS die noch älter sind und noch leichter gestört werden können.

5. Januar 2018: Von Gerald Heinig an Chris _____

"Zumal, wenn man das GPS verschlüsseln würde, was bringt das? Nichts, da die Empfänger ja das Signal irgendwie entschlüsseln müssten und dazu den Key benötigen würden. Erst eine 2-Way Kommunikation mit User/Password würde es sicherer machen"

Stichwort asymmetrische Verschlüsselung / kryptographische Signatur.

Chris, das hilft kaum weiter: asymmetrische Schlüssel sind sehr groß, typischerweise >128 byte (1024 bit, was heutztage nicht mehr als sicher angesehen wird). Dann müßte jedes Datenpaket mindestens so groß sein. Wenn ich mich richtig erinnere, sind GPS Datenpakete deutlich kleiner (ich rede nicht von Ephemeris Daten).

Normalerweise wird asymetrische Verschlüsselung nur zum Schlüsselaustausch eingesetzt, nicht zur Verschlüsselung der eigentlichen Kommunikation; das wird dann über symmetrische Verfahren gemacht (heutzutage häufig AES).

5. Januar 2018: Von Gerald Heinig an Tee Jay

Danke, vollkommen richtiges Stichwort. Interessanterweise sind symmetrische Verfahren sowas von 70er Jahre... genauso wie GPS... muss gerade schmunzeln...

In den letzten Jahrzehnten hat man mit TLS genau die gleichen Probleme durchlebt... wenn der übertragene GPS Inhalt nur mit mathematisch sicheren Algorithmen abgesichert wäre, könnte auch nichts gespooft werden.

Symmetrische Verfahren sind keineswegs veraltet: AES ist von ca. 2000 und ist hochmodern, wird in sehr vielen Chips in Hardware unterstützt und ist daher auch extrem schnell und ressourcenschonend.

Wie ich in meinem anderen Post schon gesagt habe: asymmetrische Verfahren werden aufgrund ihrem hohen Speicher- und Rechenleistungsbedarf meist als Schlüsselübergabeverfahren eingesetzt, nicht als Transportschlüssel.

5. Januar 2018: Von Gerald Heinig an Richard Georg

Auch ade von NDB, VOR und ILS die noch älter sind und noch leichter gestört werden können.

Interessanter Punkt: wieso hat (meines Wissens) noch niemand versucht, ILS zu spoofen? Wahrscheinlich, weil der Aufwand dann doch nicht so trivial ist, wie man meint, und auch weil man es mittels anderer Verfahren (DME, Höhencheck, Inertial Nav Systeme) überprüfen kann.

5. Januar 2018: Von Tee Jay an Gerald Heinig

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.

5. Januar 2018: Von Gerald Heinig an Tee Jay

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.

5. Januar 2018: Von Marco Schwan an Gerald Heinig

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.

5. Januar 2018: Von Tee Jay an Gerald Heinig

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...

5. Januar 2018: Von Andreas Ni an Richard Georg Bewertung: +1.00 [1]

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!

5. Januar 2018: Von Tee Jay an Marco Schwan

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.

5. Januar 2018: Von Gerald Heinig an Tee Jay Bewertung: +3.00 [3]

Ein Paper zu diesem Thema habe ich gerade gefunden:

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

5. Januar 2018: Von Tee Jay an Gerald Heinig Bewertung: +1.00 [1]

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

"There clearly exist circumvention techniques for all the authenticity-verification methods outlined in this survey. The mechanisms available today for protecting GNSS signals against tampering by local attackers still can at best offer a level of security comparable to most other types of tamper-resistant hardware. They all fall well short of the ambition behind the Kerckhoffs’ principle so popular in cryptology."

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.

"enforce legal restrictions on their commercial availability."

Am Ende pinkelt dann doch jemand an die Burg, und wenn es nur ein paar Nordkoreaner, Iraner., Ultra-Rechte, Ultra-Christen, Ultra-Moslems... you name it... auf Sightseeing-Tour in Washington sind...
P.S. Apropo Washington... mein Kindle am iPad sagt mir zum soeben heruntergeladenen Fire & Fury, daß die 328 Seiten etwa 7 Stunden und 8 Minuten benötigen... bin dann mal im WE... Bye!
5. Januar 2018: Von Malte Höltken an Tee Jay Bewertung: +8.00 [8]

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...

6. Januar 2018: Von Tobias Schnell an Tee Jay

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?

6. Januar 2018: Von Peter S an Tobias Schnell Bewertung: +1.00 [1]

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).

6. Januar 2018: Von Tee Jay an Peter S

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 ;-)

6. Januar 2018: Von Tobias Schnell an Peter S Bewertung: +1.00 [1]

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.

6. Januar 2018: Von Richard Georg an Andreas Ni Bewertung: +1.00 [1]

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

6. Januar 2018: Von Tee Jay an Tobias Schnell

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.

6. Januar 2018: Von Erwin Pitzer an Andreas Ni Bewertung: +3.00 [3]

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

war die "schriftliche" so grenzwertig ?


47 Beiträge Seite 1 von 2

 1 2 
 

Home
Impressum
© 2004-2024 Airwork Press GmbH. Alle Rechte vorbehalten. Vervielfältigung nur mit Genehmigung der Airwork Press GmbH. Die Nutzung des Pilot und Flugzeug Internet-Forums unterliegt den allgemeinen Nutzungsbedingungen (hier). Es gelten unsere Datenschutzerklärung unsere Allgemeinen Geschäftsbedingungen (hier). Kartendaten: © OpenStreetMap-Mitwirkende, SRTM | Kartendarstellung: © OpenTopoMap (CC-BY-SA) Hub Version 14.22.03
Zur mobilen Ansicht wechseln
Seitenanfang