Protokolldefiniton des Harmless little Board Hacko 12.11.1999 (und seiner Software Varianten fuer PCs). Dieses Protokoll soll den Informationsaustausch von verschuesselten Telefongespraechen uber TCP/IP (Internet) und Modem/ISDN dienen. Ueber beide Medien sind eins-zu-eins Verbindungen mit ganz unterschiedlichen Bedingungen zu realisieren: Modem/ISDN ========== + konstante Durchsatzraten + alle Packete kommen in der Reihenfolge an in der Sie abgeschickt wurden + konstante Latenzzeiten (kein Jitter) + niedrige Latezzeiten (<300ms einmal um die Welt) - "wenig" Durchsatz -> die roh Daten (G.711 Codec) muessen komprimiert werden - hohe kosten da direkte Telefongespraeche gefuehrt werden. - Packete koennen zerstoert werden TCP/IP ====== + Gespraeche koennen ueber LAN + WAN gefuehrt werden. + Kostenguenstig (besonders bei internationalen Verbindungen) - Latenzzeiten schwanken (Jitter) - hohe Latenzzeiten (1000ms sind International keine Seltenheit) - Reihenfolge des emfangens von Packeten nicht garantiert (UDP) - Packete koennen verloren gehen (UDP) Folgende Desingueberlegungen fuehrten zu dem implementierten Protokoll: * Fuer Modemuebertragungen sollte im Modem die eigene Fehlerkorretur ausgeschaltet werden koennen. Die Fehlerkorrekturprotokolle in Modems fuehren zu Verzoegerungen durch Handshakeing. Fehlende/zerstoerte Packete muessen bei Gespraechen nicht ersetzt werden Hauptsache der Datenfluss wird nicht unterbrochen. (Siehe diverse First-Person-Shooter (DOOM) die das genauso machen) * Es wird UDP statt TCP verwendet. Zum einen mal ist die Payload pro Packet geringer (bei UDP=28Bytes, bei TCP=40Bytes) und die TCP-Fehlerkorretur fuehrt zu stockenden Datenstroemen. * Fuer die Modemuebertragung wird der Asyncrone Modus eingesetzt. Zwar werden dann pro Byte zwei Bits fuer Start+Stopbits verwendet aber nur wenige Modems lassen sich in einen auf der Uart syncronen Modus bringen. Ausserdem koennen gewoehnliche PC-UARTs kaum mit solch einen Modus umgehen. * Das Protokoll soll am Anfang sich mit der Gegenseite auf ein Kommunikations Protokoll (also Sessionkey, Codec, Verschluesselungsmodus) einigen (aenlich der PPP-Verhandelung) * Das Protokoll muss sowohl unbestaetigten Datenfluss (fuer Gespraeche) als auch bestaetigten Datenfluss (fuer Daten deren Erhalt gewaehrleistet/kontrolliert werden muss) koennen. * Das Protokoll muss erweiterbar seinen und doch einfach. (Am liebsten sollten die Datenstruckturen in ASN.1 codiert werden aber das erzeugt mehr Payload und die Parser sind nicht leicht zu implementieren) ======================================================================== Layer 2 Modem-Layer-2 ------------- Dieser Kommunikationslayer ist so gestaltet das der Datenstrom eine moeglichst berechenbare/konstannte Datenrate aufweisst. Ein trennen von Daten und Steuerkanal (aehnlich wie bei asycronen PPP) durch wiederholen/oder nicht von DLE-Zeichen macht daher wenig Sinn. Eine Emfaenger Seite muss also den eingehenden Datenstrom solange analysieren bis ein Packet-Start-Sign auftritt. Wenn die Pruefsumme des Headers stimmt wird auch die angegebene Groesse an Packetdaten eingelesen. Wenn auch hier die 24 Bit Pruefsumme des Datenpaketes stimmt hat man hoechstwarscheinlich die richtige Stelle im Datenstrom gefunden. Sonst geht die Headeranalyse an der Stelle nach dem PSS weiter. Aufbau: 8 Bits = PSS / Packet Start Sign = 0xAA 13 Bits = RND13 / Randombits 14 Bits = HDCRC / Header CRC, lsb Bits eines CRC-32 13 Bits = LENDT / laenge des folgenden Datenpacketes (ohne nachfolgenden CRC) ---------- ~ Bis zu 8191 Bytes an Daten ~ ---------- 24 Bits = PKCRC / Packet-CRC-32 (lsb Bits) ueber den kompletten Header + Daten ========== Das sind also 9 Bytes Payload pro Packet! Der Header CRC wird wie folgt berechnet: Alle Bytes des 6 Bytes Headers werden auf Null gesetzt (0x00) dann wird das erste Byte als PSS gesetzt (0xAA) dann folgen die 13 Bytes Zufall und die 13 Bytes der Laenge Datenfeldes (high to low). Die 14 Bytes des Header CRCs sind also auf Null gesetzt. Nun wird ueber alle 6 Bytes ein CRC-32 gebildet in die 14 Bits in der mitte als Header CRC eingefuegt. Der Packet CRC wird ueber den Header(mit schon berechneten Header CRC) und das komplette Datenpacket gebildet und die 24 lsb Bits dieser Pruefsumme wird angehangen. Sollte der Header CRC stimmen aber der Packet CRC nicht muss ab dem PSS wieder nach einem neuen PSS mit gutem Header CRC suchen. Bitte beachten Sie das der Standart CRC-32 nach ANSI X3.66 als Startwert das Register mit 0xFFFFFFFF initalisiert und den Finalwert mit 0xFFFFFFFF xor't. Sein Polynom ist 0xEDB88320. IP Layer-2 ---------- Die Kommunikation wird normalerweiser ueber das UDP-Protokoll gefuehrt. Da einige Leute mit NAT Routern arbeiten die Schwierigkeiten haben eingehende UDP-Packete internen Nutzern zuzuordnen darf auch unter Umstaenden TCP verwendet werden. Dieses erhoeht die Payload pro Packet und kann zu kurzzeitigen Uebertragungsunterbrechungen fuehren (durch den sehr relaxten Wiederholungsmechnanismus bei zerstoerten Paketen) aber besser als nix. Als Portnummer sollte 4223 benutzt werden. Die Packetinformation (Dateninhalt) wird hier schon auf Pruefsummenfehler getestet. Der Layer-2 der fuer's Modem angewandt wird entfaellt also. ================================================================ HLB-Datenpacket Datenpacket im HLB-Format ------------------------- Ein Datenpacket im HLB-Format hat immer das aussehen "Daten-Header" + "Daten-Body". Daten-HEADER ============ Jedes Daten Packet beginnt 4 Bytes die Auskunft ueber den Inhalt des Datenpaketes. IMMER! (erhoeht also die Payload pro Paket um 4 Bytes). Der Daten-Header ist immer unverschluesselt! 4 Bits = VER / Version des Protokolls (momentan 0) 1 Bit = FREE1 / frei 1 Bit = DCRY / 1 = die folgenden Daten sind Verschluesselt 0 = unverschuesselt 1 Bit = DTYPE / 0 = nur Datenblock / 1 = Steuer und Dateninformation 1 Bit = SACK / Bestaetigungsanforderung (fuer diese gesammte Sequenz) 11 Bits = SEQ / Sequenznummer (beginn wird zufaellig gewaehlt) 13 Bits = LENDA / laenge des folgenden DatenBlocks (excl. der vorausgegangenen Information) VER = Version des verwendeten Protokolls (default 0) zukuenftige Erweiterungen sind also moeglich. (Wenn auch nicht erwuenscht) CDRY = Wenn dieses Bit gesetzt ist der folgende Datenblock mit dem vorher ausgehandelten Algor. verschluesselt. Wenn diese Bit null ist wird Klartext gesendet. Warnung. Unverschluesselte Daten durfen nur im angenommen werden solange noch keine Verschluesselung + Sessionkey ausgehandelt wurde. Danach ist bei Emfang solcher Packete sofort die Verbindung abzubrechen. DTYPE = Datatype. Typ des Paketes. Wenn null enhaellt das folgende Packet ausschliesslich Dateninformation (verschluesselte Gespraeche). Wenn gesetzt koennen sowohl Daten als auch Steuerinformation im Packet enthalten seien. (Den einzelnen Packeten gehen dann jeweils 2 Bytes (als Feldinformation) vorweg die sagen was fuer ein Packet und wiegross es ist). Dieses macht das Protokoll etwas komplizierter spart aber 2 Bytes konstannter Payload pro Packet. SACK = Send me an ACK. Aufforderung den Emfang dieses Packetes mit seiner SEQ im naechsten Packet zu bestaetigen. siehe STTYP = ACK SEQ = Sequenznummer des Paketes. Wird pro ausgesanntes Packet um eins erhoeht. Ermoeglicht somit die einreihung des Packetes in den Datenstrom und die erkennung von Jitter und ausfaellen. Die Nummer mit der der Transfer begonnen wird sollte zufaellig gewaehlt werden um guessing und Hijaking zu erschweren. LENDA = Laenge des folgenden Datenblocks(bodys). Gesammtlaenge ALLER folgender Informationen. Daten-BODY ========== Jeden Daten-Header folgt EIN Daten-Body pro Paket. Der Body sollte normalerweise verschluesselt sein bis auf den anfang des Verbindungsaufbaues in dem die notwendigen Informationen zum Aufbau der Verschluesselung ausgetauscht werden sollen. Bei Blockverschluesselungsalgorithmen muss die Gesammtlaenge (LENDA) normalerweise logischerweise modulo der Bitlaenge des Blockmodulos seinen. Das ist NICHT der Fall wenn beide Parteien sich vorher geeinigt haben die Daten im Cipher-feed-back Modus zu senden. Hier kann dann sozusagen aus dem Blockmodus z.B. ein 8 bit Streaming-Modus entstehen. Nuetzlich ist das in folgender Situation: Ein Codec z.B. GSM erzeugt pro Sample 33Bytes = 264Bits, IDEA verschluesselt immer nur 64Bits eines Textes. Sollen nun all 264Bits verschluesselt werden muss IDEA 5mal angewand werden und erzeugt damit 320Bits Last (7 Bytes zuviel). Wuerde IDEA nur 4mal angewand, koennen 256 Bits verschluesselt werden. Es wuerde also ein unverschluesstes Byte ueberig bleiben. Mit Cipher-feed-back Modus kann man auch das noch vermeiden ohne 7 nicht benoetigte extra bytes transportieren zu muessen. Beide Parteien muessen diesem Modus vorher zustimmen. (Siehe CFBE-Anforderung) Indem Daten-Body sind endweder aussschliesslich Rohdaten (DTYPE=0) oder (DTYPE=1) Steuerdaten und/oder Rohdaten. Bei DTYPE=1 steht daher jedem einzelnen Daten/Steuerfeld ein 2 Byteblock voran der Auskunft ueber den Feldtyp und seine Laenge gibt. Feldtyp Aufbau: --------------- 1 Bit = DFTYP / 0 = Datenfeld / 1 = Steuerfeld 1 Bit = FREE2 1 Bit = FREE3 13 Bits = LENDF / laenge des folgenden Datenfeldes insgesammt DFTYP = Wenn null ist der folgende Block ein reines Datenfeld in dem rohDaten sind. Wenn dies Bit gesetzt ist ist das folgende Feld ein Steuerfeld. Pro Steuerfeld ist nur EIN Infomationselement moeglich. LENDF = Laenge des Datenfeldes Wenn DFTYP=1 repraesentieren die ersten zwei Bytes den Typ des Informations elementes (STTYP genannt). Im einfachsten Fall reicht das schon als Information. Fuer das naechste I.E. muss also wieder ein Feldtyp mit dem naechsten Informationsfeld gesendet werden usw. . Einzelnen Informationselementen kann innerhalb des Steuerfeldes noch zusaetzliche Information zu dem Element (maximal bis ende von LENDF) folgen. STTYP Definitionen: ------------------- Folgende Informationselementtypen sind definiert: Wert IETyp Folgeinf Bedeutung ------ ----- -------- --------- 0x0000 = IDLE = var.bin Es handelt sich idle Bytes die nur gesendet werden um den Kanal immer gleich besetzt zu halten. 0x0001 = ACK = 2Bytes-i Bestaetigung einer per SACK angeforderten sequenz (LENDF=4) die urspruengliche SEQ ist so abgelegt das das nieder wertigste Bits dem niederwertigsten der 2 Bytes entspricht. 0x0002 = AYL = 2Bytes-i "Are you living?" Frage einer Seite. (mit 2Byte Zufallszahl) Wird gebraucht wenn eine Seite wissen will ob die andere noch lebt oder nur eine fette Primzahl berechnet. 0x0003 = YIASL = 2Bytes-i "Yes I am still living!" antwort der Gegenseite auf ein AYL. 0x0004 = UTUM = var.text "User to User Message" nachricht von nutzer zu nutzer soll auf dem jeweiligen Display angezeigt werden. Darf aus Sicherheitsgruenden nur auf verschluesselten Kanaelen angewandt werden. 0x0005 = MNI = var.text "my name is" Klartext indentifikation eines Nutzers gegenueber dem anderen. Darf auch unverschluesset stattfinden. Sollte nach moeglichkeit NICHT verwendet werden! Es ist als moeglichkeit Gedacht einen eventuell vorhandenen gemeinsamen Key automatisch zu verwenden wenn kein Public-Key Verfahren ausgehandelt werden konnte. (Damit der Angerufene weiss welchen Key er nehmen soll) 0x0006 = CFBE = keine Nachfrage einer Seite ob es moeglich ist die Daten im Cipher-feedback Mode zu senden. Der Modus ist Byteweise. Der Initialisierungs Vektor wird gebildet aus der Sequenznummer SEQ des jeweiligen Datenblocks. Da die nur 11Bit betraegt wird folgendes gemacht um sie zu expandieren. Die SEQ wird mit 0x4223 gexort. Die resultierende 2Byte Zahl wird sooft aneinandergehangen bis die Blockgroesse (z.B. 64Bit) erreicht ist. Padding wird wegen LENDA nicht benoetigt. Nuetzlich ist CFBE zur vermeidung von overhead der durch die Blockgroessen entsteht wenn weniger Bytes zu verschluesseln sind als da sind. 0x0007 = CFACK = keine Die andere Seite stimmt zu. 0x0008 = CFNAK = keine Die andere Seite kann das leider nicht. 0x0009 = CBCE = keine Nachfrage einer Seite ob es moeglich ist die Daten im Cipher-block chaining Mode zu senden. Der Initialisierungs Vektor wird gebildet aus der Sequenznummer SEQ des jeweiligen Datenblocks. Da die nur 11Bit betraegt wird folgendes gemacht um sie zu expandieren. Die SEQ wird mit 0x4223 gexort. Die resultierende 2Byte Zahl wird sooft aneinandergehangen bis die Blockgroesse (z.B. 64Bit) erreicht ist. Padding wird wegen LENDA nicht benoetigt. CFBE oder CBCE sollten wenn moeglich benutzt werden. 0x000A = CBACK = keine Die andere Seite stimmt zu. 0x000B = CBNAK = keine Die andere Seite kann das leider nicht. 0x0011 = PKV = 2Bytes-i Vorschlag eines Public-Key verfahrens (wird von (LENDF=4) Anrufer gesendet) Die Werte stehen in der Tabelle "Public Key". 0x0012 = PKACK = 2Bytes-i Bestaetigung des angerufenen das das vorgeschlagene (LENDF=4) Public Keyverfahren benutzt werden kann. (Wert muss nochmal wiederholt werden) 0x0013 = PKNAK = 2Bytes-i Ablehnung des angerufenen. Das vorgeschlagene (LENDF=4) Public Keyverfahren kann nicht benutzt werden. (Wert muss nochmal wiederholt werden) 0x0014 = PKAE = keine Die Aushandelung des Sessionkeys k ueber ein Public- Key-Verfahren war erfolgreich (sagt eine Seite der anderen). Wenn beide Seiten das bestaetigen kann ab dann alle Information verschluesselt ausgetauscht werden. (wird nomalerweise von jeder Seite gesendet nachdem der Session-Key entschluesselt werden konnte und damit das Symetrische-Key verfahren gestartet werden konnte) 0x0015 = PKANE = var.text Aushandelung der Public key verfahrens war aus irgendeinem Grund nicht erfolgreich. Verbindung wird abgebrochen. (Eine moeglich Fehlermeldung wird mituebertragen) 0x0021 = SCV = 2Bytes-i Vorschlag eines Symetric-key Verfahrens (wird von (LENDF=4) Anrufer gesendet) Die Werte stehen in der Tabelle "Symetric Key". 0x0022 = SCACK = 2Bytes-i Bestaetigung des angerufenen das das vorgeschlagene (LENDF=4) Symetric Keyverfahren benutzt werden kann. (Wert muss nochmal wiederholt werden) 0x0023 = SCNAK = 2Bytes-i Ablehnung des angerufenen. Das vorgeschlagene (LENDF=4) Symetric Keyverfahren kann nicht benutzt werden. (Wert muss nochmal wiederholt werden) 0x0031 = ACV = 2Bytes-i Vorschlag eines (audio) Codecs (wird von Anrufer (LENDF=4) gesendet) Die Werte stehen in der Tabelle "Codecs". 0x0032 = ACACK = 2Bytes-i Bestaetigung des angerufenen das das vorgeschlagene (LENDF=4) Codec benutzt werden kann. (Wert muss nochmal wiederholt werden) 0x0033 = ACNAK = 2Bytes-i Ablehnung des angerufenen. Der vorgeschlagene (LENDF=4) Codec kann nicht benutzt werden. (Wert muss nochmal wiederholt werden) 0x0101 = RSANP = var.bli RSA Public Key Part "n" (n = p*q (wobei p,q prim seien muessen)) 0x0102 = RSAEP = var.bli RSA Public Key Part "e" (bei e und (p-1)*(q-1) muss der kleinste gemeinsame Teiler 1 sein (relativ Prim)). e + n zusammen bilden den Public Key einer Seite. 0x0103 = RSACE = var.bli RSA verschluesselte Nachricht "c" im nomalfall der gewaehlte Sessionkey "k" (c = k^e mod n) 0x0121 = ELGPP = var.bli ElGamal Public Key Part "p" (wobei p eine Primzahl ist) 0x0122 = ELGGP = var.bli ElGamal Public Key Part "g" (wobei g < p ist) 0x0123 = ELGYP = var.bli ElGamal Public Key Part "y" (y = g^x mod p). Die Teile p,g+y zusammen bilden den Public Key einer Seite. 0x0124 = ELGAE = var.bli ElGamal verschluesselte Nachricht Teil "a" (wird gebildet aus a = g^z mod p, wobei z random ist fuer und relativ Prim zu (p-1)) 0x0125 = ELGBE = var.bli ElGamal verschluesselte Nachricht Teil "b" (wird gebildet aus b = y^z*k mod p) Teil a und b zusammen bilden eine verschluesselte Nachricht die meist den Session Key k transportiert. 0x0131 = DHNP = var.bli DiffieHellman Public Key Part "n" ist eine grosse Primzahl wobei (n-1)/2 auch Prim seinen muss 0x0132 = DHGP = var.bli DiffieHellman Public Key Part "g" 0x0133 = DHXAE = var.bli DiffieHellman Nachricht von den Anrufer zum angerufenen um den Sessionkey k zu erzeugen 0x0134 = DHYBE = var.bli DiffieHellman Nachricht vom angerufenen zum anrufer um den Sessionkey k zu erzeugen Grundsaetzliche Ueberlegenungen ueber den Austausch von Steuerinformationen. Da der Anfang des Protokolls ja unverschluesselt ist sollte moeglichst schnell alles an Information ausgetauscht werden um den Kanal verschluesseln zu koennen. Da bei den wohl meisten Scenarios in dem eine Telefonleitung benutzt wird der Anrufer die Verbindungskosten traegt, bestimmt dieser auch die Wahl der verwendeten Verfahren. Der Angerufene kann ein Verfahren ablehnen (z.B. weil der Algorithmus nicht bei ihm implementiert ist oder er weiss, dass die vorgeschlagene Keygroesse bei ihm wahnsinning lange braucht (>5Minuten) um berechnet zu werden) der anrufer kann dann ein neues vorschlagen. Wenn keines zustandekommt wird die Verbindung abgebrochen (meist von der Anrufer Seite da nur er ja weiss ob er noch ein anderes Verfahren vorschlagen kann). Dabei ist zu beachten das zwar kein Public-Key Verfahren ausgehandelt seinen muss wohl aber ein Symetric-Key Verfahren (wenn beide vorher ein gemeinsames geheimes Passwort vereinbart haben). Die Aushandelung der Parameter geschieht in 3 festen Stufen die immer gleich aussehen. Stufe 1.) Aushandelung der Public und Symetric-Key Verfahren. Der Anrufer fragt den angerufenen welche Verfahren benutzt werden koennen. Abgeschlossen ist diese Stufe wenn der angerufene PKACK + SCACK gesendet hat. Stufe 2.) Uebermittlung/Berechung des Session keys duch das Public-Key Verfahren. Bei den Public-Key Verfahren RSA+ElGamal generiert der anrufer einen Session-Key mit seinem Secret und dem Public Key des angerufenen (woraus folgt das in dieser Stufe erst beide Seiten sich ihre Public Keys austauschen) und sendet ihm diesen Key. Der angerufene MUSS diesen entschluesseln und umgekehrt zurueck schicken (also mit seinem geheimen und dem Public-Key des anrufers wieder verschluesseln) damit der anrufer die Moeglichkeit hat zu kontrollieren ob eine man-in-the-middle-attacke vorliegt. Abgeschlossen ist diese Stufe wenn BEIDE Seiten ein PKAE gesendet haben. Wenn das bendet ist wird ab dann jeglicher Datenverkehr verschluesselt! Stufe 3.) Codec aushandelung. Abgeschlossen ist diese Stufe wenn der angerufene ein ACACK gesendet hat. Danach kommt die eigendliche Verbindungsphase in der endlich verschluesselt gelabert werden kann. :-) Beispiel eines Verbindungsausbaues (es wird nur die Steuerinformation angezeigt) Anrufer Angerufener Bemerkung ------- ----------- --------- ~ ~ PKV[0021] ~ Er will gerne RSA 4096 SCV[0012] ---> ~ Triple-DES als Symetrisches ~ ~ Verfahren ~ ~ ~ PKNACK[0021] RSA mit 4096 is nich ~ <--- SCACK[0012] Triple-DES ist ok. ~ ~ PKV[0013] ---> ~ Koennen wir den ElGamal 1024? ~ ~ ~ <--- PKACK[0013] Ja das geht klar (Stufe 1 ist somit ~ ~ fertig) ~ ~ ELGPP[zahl] ~ ELGGP[zahl] ~ ELGYP[zahl] ---> ~ Public - Key des Anrufers ~ ~ ~ ELGPP[zahl] ~ ELGGP[zahl] ~ <---- ELGYP[zahl] Public - Key des Angerufenen ~ ~ ~ ~ ~ ~ ELGAE[zahl] ~ ELGBE[zahl] ----> ~ Verschluesselter Session Key ~ ~ ~ ~ ~ ~ AYL[34fe] ----> ~ Das dauert solange lebst du noch? ~ <---- YIASL[34fe] Ja! Halt's Maul! ~ ~ ~ ELGAE[zahl] ~ ELGBE[zahl] Zuruecksendung des Session-Keys ~ <---- PKAE Bei mir ist alles klar. ~ ~ ~ ~ PKAE ----> ~ Ich hab's geprueft und auch hier ist ~ ~ alles klar. ~ ~ (Stufe 2 ist jetzt beendet. Ab jetzt ~ ~ ist der Kanal verschluesselt) ACV[0001] ----> ~ kannst du GSM? ~ <---- ACACK[0001] Kann ich wohl. (ende Stufe 3) ~ ~ Jetzt koennen erst Daten und nicht nur Steuerinformation ausgerauscht werden! ======================================================================= Tabellen Tabelle: Public Key (asymetric) Nummer Name Keylen(bit) ------ ---- ----------- 0x0000 keines 0 Note: Kann benutzt werden wenn kein Public Key Verfahren ausgehandelt werden konnte und daher kein Sessionkey exsistiert. Beide Parteien muessen dann ueber einen gemeinsamen vorher ausgehandelten geheimen Schluessel verfuegen. 0x0001 DiffieHellman 4096 0x0002 DiffieHellman 2048 0x0003 DiffieHellman 1024 0x0004 DiffieHellman 512 0x0011 ElGamal 4096 0x0012 ElGamal 2048 0x0013 ElGamal 1024 0x0014 ElGamal 512 0x0021 RSA 4096 0x0022 RSA 2048 0x0023 RSA 1024 0x0024 RSA 512 Note: Da RSA in den USA patentiert ist bitte DORT bis zum 20Sep.2000 nicht benutzen. Ein weiteres Problem ist die Speicherung des private Key. Der kann aus Sicherheitsgruenden nicht auf dem Telefon gelagert werden sondern muss auf einer Smartcard ausgelagert werden (dito ElGamal). Alle Public Key Verfahren sind potentiell verwundbar gegen man-in-the-middle Attacken! Das gilt besonders fuer Diffie-Hellman da der "Public-Key" jeder Seite jedesmal anders aussieht und nicht mit vorherigen Keys verglichen werden kann. Fuer RSA und ElGamal waeren Key-Zertifikate eine Loesung wenn sie fuer das Telefondevice auch in ihrgendeiner Form kontrollierbar waeren. (Es muss bei der Zerifizierungsstelle nachfragen koennen.) Das ist unter Umstaenden machbar erzeugt aber einen ungewollten Datenschatten (durch den Anruf/IP-Verbindung). Oder sich darauf VERLASSEN KOENNEN das der ihm (im ROM) eingebrannte Key der Zertifzierungsstelle richtig ist und nicht manipuliert. Heikel... Heikel... Besser ist es daher die Verbindung erstmal verschluesselt anzunehmen und dann folgendes zu machen: Die gemeinsam ausgehandelte Session Key k (der nur fuer diese eine Sitzung gilt) wird auf jeder Seite durch einen Hash-Algorithmus geschickt (z.B. MD5) und ein paar Bytes des Hashwertes in das Display eines jeden Nutzers geschrieben (oder ihm vom System ueber's Telefon vorgelesen). Bevor das Gespraech dann richtig anfaengt liest eine Seite der anderen (ueber die inzwischen verschluesselte Leitung) ihren Hash vor (mit gleichzeitiger menschlichen Stimmidentifikation). Wenn Hash nicht stimmt muss die Kommunikation sofort eingestellt werden (und alle Beweise vernichtet, das Haus abgebrannt und nach Neuseeland ausgewandert werden). :-) Da es hier mehrere moeglichkeiten gibt MUSS folgendes von jeder HLB-Implementation unterstuetzt werden, alles andere ist optional. Die Hashalgorithmen MD5 + SHA-1 werden benutzt. Das Ergebniss beider Werte wird in's Display geschrieben und zwar in Hex beginnend mit dem LSB (also niedrigster Wert). Das HLB als Standalonedevice kann in seinem Display 16 Zeichen in 2 Zeilen anzeigen. In der ersten Zeile steht dann der MD5 Wert in der 2.ten der SHA-1 Wert. Immer beginnend mit den niederigsten Bytes. So lassen sich auf einen Blick 2*8 Hashbytes ueberblicken und ueberpruefen. Je mehr davon ueberprueft wird umso besser. Das ist die entscheidung des Nutzers. Fuer RSA und ElGamal ist dieses Verfahren NUR noetig wenn noch nie mit der gegenueber liegenden Seite kommuniziert wurde und daher keine eigene Kopie ihres Public-Key zur Pruefung vorliegt (der sicher (Smartcard) verwahrt seinen muss). Wir emfehlen aber das trotzdem fuer den Nutzer jedesmal anzuzeigen damit er sich daran gewoehnt. Tabelle: Symetric Key (block + stream) Nummer Name Blocklen(bit) Keylen(bit) ------ ---- ------------- ----------- 0x0000 keine 0 0 nur fuer debugging und gewisse Zulassungsprobleme erlaubt 0x0001 Blowfish 64 448 0x0002 Blowfish 64 256 0x0003 Blowfish 64 128 0x0011 DES 64 56 0x0012 TripleDES 64 168 0x0021 IDEA 64 128 0x0022 GOST 64 256 0x0023 CAST 64 64 0x0031 Twofish 128 128 0x0032 Twofish 128 256 Note: Blowfish sollte als Standardalgorithmus impletmentiert seinen. Bitte bitte DES nicht benutzen (wenn schon dann Triple-DES)! Er ist nur fuer die US-Importversion vorgesehen. Bei komerzieller Nutzung von IDEA bitte Lizensgebuehren zahlen nicht vergessen! Twofish wird als AES Kandidat gehandelt. Wegen der Blockgroesse kann aber mehr Protokolloverhead entstehen. Andere Verfahren wie RC4,RC5 + SEAL sind meist irgendwo Patentiert und daher nicht nutzbar. Sorry Guys nix zu tuen fuer eure Rechtsanwaelte dann nehm' ich das Zeug einfach nicht! Tabelle: Codecs Nummer Name Blocklen Framesize Frames/s Bit/s Mode ------ ---- -------- --------- -------- ----- ---- 0x0000 keiner 0 0 0 0 kein Codec verwendet ~ ~ ~ ~ ~ ~ (nur Datenueber- ~ ~ ~ ~ ~ ~ mittlung) 0x0001 GSM 33 Byte 6,25ms 50 13200 GSM 6.10 0x0011 LPC-10 54 Bit 5,5555ms 44,4444 2400 0x0021 G.711 1 Byte 125us 8000 64000 alaw 0x0022 G.711 1 Byte 125us 8000 64000 ulaw Note: Der GSM 6.10 sollte in jeder Implemenation vorhanden sein. Die freie implementation von der TU-Berlin ist auch mit Fixpoint CPUs >40Mips zu beherrschen. Der LPC-10 Codec ist bisher nur in Floating-Point Implementationen vorhanden. Es sollten vier Frames zusammengefasst verschickt werden (einmal um auf Bytealign zu kommen und um unnoetigen Protokoll overhead zu vermeiden). Kann aber aufgrund seiner geringen Bandbreite mit GSM-Modems (nur 9600bit/s) verwendet werden (obwohl er etwas syntetisch klingt). Der G.711 Codec (also normale ISDN Qualitaet) kann aufgrund seiner erforderlichen Bitgeschindigkeit nur im LAN, bei GUTEN Internetanbindungen oder mit ISDN Kanalbuendelung operieren. Obwohl sein "Design" simpel ist sollte er nur im LAN Anwendung finden. =================================================================== Sicherheit Noch einige Worte zu Thema Sicherheit/Big Brother! 1.) Warum erlauben wir ueberhaupt schwache (DES 56bit und P.K.-Verfahren mit 512 bit) oder sogar GARKEINE Verschluesselung? Dazu zwingt uns leider die Politik einiger Laender (USA/Frankreich/China u.s.w.). Wir wollen nicht das das Teil/Protokoll nicht benutzt wird/verboten ist weil wir nur Strong-encryption machen. Viel eher setzen wir darauf das man die low/no-encryption Version offiziel einsetzt/vorzeigt aber die scharfe dann wirklich benutzt. (Notfalls halt als Webphone in dem jeweiligen Land zulassen aber dann woanders ein "gutes" Eprom brennenlassen und reinstecken). Die sogenannte U.S.-Importversion (DES 56bit und P.K.-Verfahren mit 512 bit) ist mehr ein Seitenhieb auf die Crypto-Politik der USA. Wir wissen sehr wohl dass man in die USA gute Verfahren importieren aber nicht (frei) exportieren darf (und dass die USA auch ihren "Verbuendeten" low-crypto vorschreiben will). Solange sich das nicht darstisch aendert bestehen wir fuer die USA auf low-crypto! :-) 2.) Was ist mit kompromitierender Strahlung / Tempest? Hmm.. Sicherer wuerde es seinen wenn Sie das HLB in zwei-drei ineinander geschachtelte Keksdosen packen, die Stromversorgung mittels einer Batterie betrieben, alle Leitungen mehrfach galvanisch trennen und zusaetzlich alle Waende und Fenster mit Alufolie bekleben. Aber im Ernst, das Device wird warscheinlich strahlen wie jedes digitale Telefon/Computer. Selbst haerteste EMV-Vorschriften verhindern nicht das jemand die Strahlung eines Monitors auffaengt und sichtbar macht. Es gibt zwar teure anti Tempest Geraete aber niemand kann sagen ob das wirklich taugt. Wir wissen es nicht! Man kann im Design gewisse massnahmen treffen aber die werden nicht wirklich helfen. Das HLB hat zumindest schon mal keinen Monitor der strahlt sondern nur ein LCD. Wenn man eine Gummitastatur einsetzt werden harte Prellpegel auch nicht entstehen. Die CPU wird strahlen wie jede CPU aber das wird wohl kaum analysierbar seien. Um den AD/DA-wandler sollte man allerdings nach moeglichkeit ein kleines extra Blechgehaeuse machen. Dies ist vermutlich auch der Schwachpunkt in einer PC-Modem-Soundkarten Installation. 3.) Manipulationssicherheit? Das Protokoll in sich duerfte sicher sein. Es sind zwar keine zusaetzlichen Authentisierungen waehrend des Gespaeches vorgesehen aber wenn jemand diese Packte manipuliert erzeugt er auf der decodierenden Seite nur weisses Rauschen. Diese Stoerungen sollten einem zu denken geben. Das Geraet selber ist nur sicher wenn nur Sie physikalischen Zugriff haben (genau wie ihr PC). Sie sollen ein verplomptes Gehaeuse benutzen, die Sourcen uebersetzten und das Eprom dafuer selber brennen. Das ist MEHR Schutz als jedes kommerzielle Geraet ihnen bieten kann. Keys sollten nicht auf dem Geraet selber gelagert werden. Wenn man sie auf eine Smartcard auslagert kann man sie immer dabei haben und im Auge behalten. 4.) Big Brother / Echelon? Das HLB/Protokoll soll eigendlich gegen grossflaechige Lauschangriffe schuetzen. Scannen nach bestimmten Woerten (z.B. "bombe" + "kanzler") wird damit gut unterbunden. Die decodierung von V.34 Modemsignalen ist technisch aufwendiger aber nicht unmachbar. Die Sicherheit ensteht nur durch Cryptografische verfahren mit anstaendigen Keylaengen. Trotzdem tauchen Sie dann unvermittelt aus der Menge heraus. Schliesslich muss es ein genormtes Protokoll geben um komunizieren zu koennen. Nach diesem kann aber auch der Gegner suchen und erfaehrt so das Sie was zu verbergen haben. Sie koennen zwar versuchen das Prokokoll durch ein anderes zu Tunneln (z.B. IPSec) aber das erhoeht immer den Overhead, macht die Kontaktaufnahme mit der anderen Seite schwierig und weisst auch wieder auf sie hin (nur eben anders). Aus diesem Dilemma gibt es keinen Ausweg. Entweder Sie ignorieren diesen Umstand oder sorgen aktiv mit fuer eine breite verbreitung/haeufige benutzung um dann wieder in der Menge zu verschwinden. 5.) Was ist mit anderen kryptografischen Verfahren / Voice codecs? Wir wollen erstmal mit einem sinnvollen set an den Start gehen. Andere kommen wenn wir es fuer sinnvoll halten, die verwendung fuer den privaten Nutzer frei ist und der Source implementierbar ist. Bis dahin gilt die Regel:"This is a Useroption. If the User wants it, he writes it!" Wir geben die Quellcodes heraus ihr koennt euch also selber ranmachen. =================================================================== Berechnungen Geschwindigkeitsberechnungen: ----------------------------- Worstcase Async: 9 Bytes Modem Layer 2 Payload 4 Bytes Datenpacketinformation 33 ein GSM Frame entspricht (20ms Gespraechs-Information) --- 46 Bytes / 8 * 10 (Startstopinfo) = 460Bits * 50Frames = 23000Bit/s min. Gesammtdurchsatz Worstcase Async UDP ueber PPP (Modem macht dann intern Syncron + Fehlerkorrektur): 28 UDP Header 4 Bytes Datenpacketinformation 33 ein GSM Frame entspricht (20ms Gespraechs-Information) --- 65 Bytes * 8 Bits = 520Bits * 50Frames = 26000Bits/s + 5% PPP Overhead ~ 27300Bits/s min. Gesammtdurchsatz Es ist also zwar moeglich jedes GSM-Frame einzeln zu verschicken aber es geht nahe an die Grenze. Es sollten daher 2-3 Frames pro Datenpacket verschickt werden. ==================================================================== Schaubilder Zaehlweise: Bitindex[1] ist das niederwertigste Bit in einem Byte. Bitindex[0] ist NICHT ZULAESSIG. ----------Packetheader Beginn---- - Byte 1 PSS [ 8] = 1 PSS [ 7] = 0 PSS [ 6] = 1 PSS [ 5] = 0 PSS [ 4] = 1 PSS [ 3] = 0 PSS [ 2] = 1 PSS [ 1] = 0 - Byte 2 RND13 [13] RND13 [12] RND13 [11] RND13 [10] RND13 [ 9] RND13 [ 8] RND13 [ 7] RND13 [ 6] - Byte 3 RND13 [ 5] RND13 [ 4] RND13 [ 3] RND13 [ 2] RND13 [ 1] HDCRC [14] HDCRC [13] HDCRC [12] - Byte 4 HDCRC [11] HDCRC [10] HDCRC [ 9] HDCRC [ 8] HDCRC [ 7] HDCRC [ 6] HDCRC [ 5] HDCRC [ 4] - Byte 5 HDCRC [ 3] HDCRC [ 2] HDCRC [ 1] LENDT [13] LENDT [12] LENDT [11] LENDT [10] LENDT [ 9] - Byte 6 LENDT [ 8] LENDT [ 7] LENDT [ 6] LENDT [ 5] LENDT [ 4] LENDT [ 3] LENDT [ 2] LENDT [ 1] ----------Ende des Packetheaders---- - Byte 7 ----------Anfang des Datenheaders---- VER [ 4] VER [ 3] VER [ 2] VER [ 1] FREE1 [ 1] DCRY [ 1] DTYPE [ 1] = 1 SACK [ 1] - Byte 8 SEQ [11] SEQ [10] SEQ [ 9] SEQ [ 8] SEQ [ 7] SEQ [ 6] SEQ [ 5] SEQ [ 4] - Byte 9 SEQ [ 3] SEQ [ 2] SEQ [ 1] LENDA [13] LENDA [12] LENDA [11] LENDA [10] LENDA [ 9] - Byte 10 LENDA [ 8] LENDA [ 7] LENDA [ 6] LENDA [ 5] LENDA [ 4] LENDA [ 3] LENDA [ 2] LENDA [ 1] ----------Ende des Datenheaders---- - Byte x (LENDA = 1) ----------Anfang der Datenfelddef. (Feldtyp) ---- DFTYP [ 1] = 0 FREE2 [ 1] FREE3 [ 1] LENDF [13] LENDF [12] LENDF [11] LENDF [10] LENDF [ 9] - Byte x (LENDA = 2) LENDF [ 8] LENDF [ 7] LENDF [ 6] LENDF [ 5] LENDF [ 4] LENDF [ 3] LENDF [ 2] LENDF [ 1] ----------Ende des Datenfelddef.---- - Byte x (LENDF = 1) ----------Anfang des Datenbodys---- ~ ~ ~ ~ ----------Ende des Datenbodys---- - Byte x (LENDA = ) ----------Anfang der Datenfelddef. (Feldtyp) ---- DFTYP [ 1] = 1 FREE2 [ 1] FREE3 [ 1] LENDF [13] LENDF [12] LENDF [11] LENDF [10] LENDF [ 9] - Byte x (LENDA = 2) LENDF [ 8] LENDF [ 7] LENDF [ 6] LENDF [ 5] LENDF [ 4] LENDF [ 3] LENDF [ 2] LENDF [ 1] ----------Ende des Datenfelddef. (Feldtyp) ---- - Byte x (LENDF = 1) ----------Anfang des Steuerfeldbodys---- STTYP [16] STTYP [15] STTYP [14] STTYP [13] STTYP [12] STTYP [11] STTYP [10] STTYP [ 9] - Byte x (LENDF = 2) STTYP [ 8] STTYP [ 7] STTYP [ 6] STTYP [ 5] STTYP [ 4] STTYP [ 3] STTYP [ 2] STTYP [ 1] - Byte x (LENDF = 3) ~ ~ ~ ~ ~ ~ ----------Ende des Steuerfeldbodys---- - Byte x (LENDT+1) ----------Anfang der Packetpruefsumme---- PKCRC [24] PKCRC [23] PKCRC [22] PKCRC [21] PKCRC [20] PKCRC [19] PKCRC [18] PKCRC [17] - Byte x (LENDT+2) PKCRC [16] PKCRC [15] PKCRC [14] PKCRC [13] PKCRC [12] PKCRC [11] PKCRC [10] PKCRC [ 9] - Byte x (LENDT+3) PKCRC [ 8] PKCRC [ 7] PKCRC [ 6] PKCRC [ 5] PKCRC [ 4] PKCRC [ 3] PKCRC [ 2] PKCRC [ 1] ----------Ende der Packetpruefsumme---- ################ ----------Packetheader Beginn---- - Byte 1 PSS [ 8] = 1 PSS [ 7] = 0 PSS [ 6] = 1 PSS [ 5] = 0 PSS [ 4] = 1 PSS [ 3] = 0 PSS [ 2] = 1 PSS [ 1] = 0 - Byte 2 RND13 [13] RND13 [12] RND13 [11] RND13 [10] RND13 [ 9] RND13 [ 8] RND13 [ 7] RND13 [ 6] - Byte 3 RND13 [ 5] RND13 [ 4] RND13 [ 3] RND13 [ 2] RND13 [ 1] HDCRC [14] HDCRC [13] HDCRC [12] - Byte 4 HDCRC [11] HDCRC [10] HDCRC [ 9] HDCRC [ 8] HDCRC [ 7] HDCRC [ 6] HDCRC [ 5] HDCRC [ 4] - Byte 5 HDCRC [ 3] HDCRC [ 2] HDCRC [ 1] LENDT [13] LENDT [12] LENDT [11] LENDT [10] LENDT [ 9] - Byte 6 LENDT [ 8] LENDT [ 7] LENDT [ 6] LENDT [ 5] LENDT [ 4] LENDT [ 3] LENDT [ 2] LENDT [ 1] ----------Ende des Packetheaders---- - Byte 7 ----------Anfang des Datenheaders---- VER [ 4] VER [ 3] VER [ 2] VER [ 1] FREE1 [ 1] DCRY [ 1] DTYPE [ 1] = 0 SACK [ 1] - Byte 8 SEQ [11] SEQ [10] SEQ [ 9] SEQ [ 8] SEQ [ 7] SEQ [ 6] SEQ [ 5] SEQ [ 4] - Byte 9 SEQ [ 3] SEQ [ 2] SEQ [ 1] LENDA [13] LENDA [12] LENDA [11] LENDA [10] LENDA [ 9] - Byte 10 LENDA [ 8] LENDA [ 7] LENDA [ 6] LENDA [ 5] LENDA [ 4] LENDA [ 3] LENDA [ 2] LENDA [ 1] ----------Ende des Datenheaders---- - Byte x (LENDA=1) ----------Anfang des Datenbodys---- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ----------Ende des Datenbodys---- - Byte x (LENDT+1) ----------Anfang der Packetpruefsumme---- PKCRC [24] PKCRC [23] PKCRC [22] PKCRC [21] PKCRC [20] PKCRC [19] PKCRC [18] PKCRC [17] - Byte x (LENDT+2) PKCRC [16] PKCRC [15] PKCRC [14] PKCRC [13] PKCRC [12] PKCRC [11] PKCRC [10] PKCRC [ 9] - Byte x (LENDT+3) PKCRC [ 8] PKCRC [ 7] PKCRC [ 6] PKCRC [ 5] PKCRC [ 4] PKCRC [ 3] PKCRC [ 2] PKCRC [ 1] ----------Ende der Packetpruefsumme---- ======================================================================= Anhang A Referenz Dokumente 1.) Buch: "Applied Cryptography" von Bruce Schneier 2.) Buch: "TCP/IP Illustrated V.1" von Richard W. Stevens