Poznámka
Fáze návrhu je uzavřena. Viz SPEC pro oficiální specifikaci. Tento návrh může být stále využíván jako podkladová informace.
Přehled
Tento návrh popisuje protokol pro autentizovanou dohodu o klíčích, který má zlepšit odolnost NTCP vůči různým formám automatizované identifikace a útokům.
Návrh je organizován následovně: jsou prezentovány bezpečnostní cíle, následuje diskuse základního protokolu. Dále je poskytována kompletní specifikace všech protokolových zpráv. Nakonec jsou diskutovány adresy routerů a identifikace verzí. Součástí je také dodatek diskutující obecný útok na běžná schémata paddingu, stejně jako dodatek obsahující řadu kandidátů pro autentizovanou šifru.
Stejně jako ostatní I2P transporty, NTCP2 je definován výhradně pro point-to-point (router-to-router) transport I2NP zpráv. Není to univerzální datový kanál.
Motivace
NTCP data jsou šifrována po první zprávě (a první zpráva vypadá jako náhodná data), což zabraňuje identifikaci protokolu prostřednictvím “analýzy obsahu”. Stále je však zranitelný vůči identifikaci protokolu prostřednictvím “analýzy toku”. Je to proto, že první 4 zprávy (tj. handshake) mají pevnou délku (288, 304, 448 a 48 bajtů).
Přidáním náhodných množství náhodných dat ke každé ze zpráv můžeme situaci výrazně ztížit.
Autoři uznávají, že standardní bezpečnostní postupy by navrhovaly použití existujícího protokolu jako je TLS, ale to je Prop104 a má své vlastní problémy. Kde je to vhodné, byly přidány odstavce “budoucí práce” k označení chybějících funkcí nebo předmětů diskuse.
Cíle návrhu
Podpora NTCP 1 a 2 na jednom portu, automatická detekce a publikování jako jediný “transport” (tj. RouterAddress) v NetDB.
Publikovat podporu pouze pro verzi 1, pouze 2, nebo 1+2 v NetDB v samostatném poli a výchozí nastavení na pouze verzi 1 (nevazovat podporu verzí na konkrétní verzi routeru)
Zajistit, aby všechny implementace (Java/i2pd/Kovri/go) mohly přidat podporu verze 2 (nebo ne) podle svých vlastních harmonogramů
Přidat náhodné doplnění do všech NTCP zpráv včetně handshake a datových zpráv (tj. zamaskování délky tak, aby všechny zprávy nebyly násobkem 16 bajtů) Poskytnout mechanismus možností pro obě strany k vyžádání minimálního a maximálního doplnění a/nebo distribuce doplnění. Specifika distribuce doplnění závisí na implementaci a mohou nebo nemusí být specifikována v samotném protokolu.
Obfuskovat obsah zpráv, které nejsou šifrované (1 a 2), dostatečně tak, aby DPI boxy a AV signatury je nemohly snadno klasifikovat. Také zajistit, aby zprávy směřující k jednomu peer nebo skupině peers neměly podobný vzor bitů.
Oprava ztráty bitů v DH kvůli formátu Java Ticket1112, možně (pravděpodobně?) přechodem na X25519.
Přejít na skutečnou funkci derivace klíčů (KDF) namísto používání DH výsledku tak, jak je?
Přidat “odolnost proti sondování” (jak to nazývá Tor); zahrnuje to odolnost proti replay útokům.
Udržovat obousměrnou autentifikovanou výměnu klíčů (2W-AKE). 1W-AKE není pro naši aplikaci dostatečné.
Pokračovat v používání podpisů s variabilním typem a variabilní délkou (z publikovaného podpisového klíče RouterIdentity) jako součást autentifikace. Spoléhat na statický veřejný klíč publikovaný v RouterInfo jako další část autentifikace.
Přidat možnosti/verzi do handshake pro budoucí rozšiřitelnost.
Přidat odolnost proti škodlivé TCP segmentaci MitM, pokud je to možné.
Nezvyšujte výrazně požadavky na CPU pro navázání spojení; pokud je to možné, výrazně je snižte.
Přidat autentifikaci zpráv (MAC), pravděpodobně HMAC-SHA256 a Poly1305, a odebrat Adler kontrolní součet.
Zkrátit a zjednodušit I2NP hlavičku: Zkrátit expiraci na 4 byty, jako v SSU. Odstranit jednobytový zkrácený SHA256 kontrolní součet.
Pokud je to možné, snížit 4-zprávy, dvoufázový handshake na 3-zprávy, jednofázový handshake, jako v SSU. To by vyžadovalo přesunutí Bobova podpisu ze zprávy 4 do zprávy 2. Prozkoumat důvod pro 4 zprávy v desetiletých archivech emailů/stavů/schůzek.
Minimalizujte režijní náklady protokolu před paddingem. Ačkoliv bude přidán padding, a možná ho bude hodně, režie před paddingem je stále režie. Uzly s nízkou šířkou pásma musí být schopny používat NTCP2.
Udržovat časové značky pro detekci opakování a zkosení.
Vyhněte se jakýmkoli problémům roku 2038 v časových razítkách, musí fungovat alespoň do roku 2106.
Zvětšit maximální velikost zprávy ze 16K na 32K nebo 64K.
Jakékoli nové kryptografické primitivy by měly být snadno dostupné v knihovnách pro použití v implementacích routerů v Java (1.7), C++ a Go.
Zahrnout zástupce vývojářů routerů v Javě, C++ a Go do návrhu.
Minimalizovat změny (ale stále jich bude hodně).
Podporovat obě verze ve společné sadě kódu (to nemusí být možné a v každém případě závisí na implementaci).
Non-Goals
Neprůstřelná odolnost vůči DPI… to by byly pluggable transports, Prop109.
TLS-based (nebo HTTPS-lookalike) transport… což by bylo Prop104.
Je v pořádku změnit symetrickou proudovou kryptografii.
Odolnost proti DPI založené na časování (časování/zpoždění mezi zprávami může být závislé na implementaci; zpoždění uvnitř zpráv může být zavedeno v jakémkoli bodě, včetně před odesláním náhodného paddingu, například). Umělá zpoždění (to, co obfs4 nazývá IAT nebo inter-arrival time) jsou nezávislá na samotném protokolu.
Popiratelnost účasti v relaci (jsou tam podpisy).
Necíle, které mohou být částečně přehodnoceny nebo diskutovány:
Stupeň ochrany proti Deep Packet Inspection (DPI)
Post-Quantum (PQ) zabezpečení
Popíratelnost
Related Goals
- Implementovat testovací nastavení NTCP 1/2
Security Goals
Uvažujeme tři strany:
- Alice, která si přeje navázat novou relaci.
- Bob, se kterým si Alice přeje navázat relaci.
- Mallory, “muž uprostřed” mezi Alice a Bobem.
Aktivní útoky může provádět maximálně dva účastníci.
Alice a Bob mají oba ve svém vlastnictví statický pár klíčů, který je obsažen v jejich RouterIdentity.
Navrhovaný protokol se pokouší umožnit Alici a Bobovi dohodnout se na sdíleném tajném klíči (K) za následujících požadavků:
Bezpečnost soukromého klíče: ani Bob ani Mallory se nedozvědí nic o Alicině statickém soukromém klíči. Symetricky, Alice se nedozvědí nic o Bobově statickém soukromém klíči.
Klíč relace K zná pouze Alice a Bob.
Perfektní forward secrecy: dohodnutý session key zůstává tajný i v budoucnosti, i když jsou statické privátní klíče Alice a/nebo Boba odhaleny poté, co byl klíč dohodnut.
Obousměrné ověření: Alice má jistotu, že navázala relaci s Bobem, a naopak.
Ochrana proti online DPI: Zajistit, že není triviální detekovat, že se Alice a Bob účastní protokolu pouze pomocí jednoduchých technik deep packet inspection (DPI). Viz níže.
Omezená popiratelnost: ani Alice ani Bob nemohou popřít účast v protokolu, ale pokud jedna ze stran prozradí sdílený klíč, druhá strana může popřít pravost obsahu přenášených dat.
Tento návrh se pokouší splnit všech pět požadavků na základě protokolu Station-To-Station (STS). Poznamenejme, že tento protokol je také základem pro protokol SSU.
Additional DPI Discussion
Předpokládáme dvě DPI komponenty:
1) Online DPI
Online DPI kontrolující všechny toky v reálném čase. Připojení mohou být blokována nebo jinak pozměňována. Data připojení nebo metadata mohou být identifikována a uložena pro offline analýzu. Online DPI nemá přístup k I2P síťové databázi. Online DPI má pouze omezenou výpočetní kapacitu v reálném čase, včetně výpočtu délky, kontroly polí a jednoduchých výpočtů jako je XOR. Online DPI má schopnost rychlých kryptografických funkcí v reálném čase jako jsou AES, AEAD a hashovací funkce, ale ty by byly příliš nákladné pro aplikaci na většinu nebo všechny toky. Jakákoli aplikace těchto kryptografických operací by se vztahovala pouze na toky na IP/Port kombinacích dříve identifikovaných offline analýzou. Online DPI nemá schopnost kryptografických funkcí s vysokou režií jako jsou DH nebo elligator2. Online DPI není navrženo specificky pro detekci I2P, ačkoli může mít omezená klasifikační pravidla pro tento účel.
Cílem je zabránit identifikaci protokolu online DPI.
Pojem online nebo „přímočaré" DPI zde zahrnuje následující schopnosti protivníka:
Schopnost kontrolovat všechna data odeslaná nebo přijatá cílem.
Schopnost provádět operace s pozorovanými daty, jako je aplikování blokových šifer nebo hash funkcí.
Schopnost ukládat a porovnávat s dříve odeslanými zprávami.
Schopnost modifikovat, zpozdit nebo fragmentovat pakety.
Nicméně se předpokládá, že online DPI má následující omezení:
Nemožnost mapování IP adres na hashe routerů. Ačkoliv je to triviální při přístupu k síťové databázi v reálném čase, vyžadovalo by to DPI systém specificky navržený pro cílení na I2P.
Neschopnost použít informace o časování k detekci protokolu.
Obecně řečeno, online DPI toolbox neobsahuje žádné vestavěné nástroje, které by byly specificky navrženy pro detekci I2P. To zahrnuje vytváření “honeypotů”, které by například obsahovaly nenáhodné padding ve svých zprávách. Všimněte si, že to nevylučuje systémy strojového učení nebo vysoce konfigurovatelné DPI nástroje, pokud splňují ostatní požadavky.
Pro boj proti analýze datové části je zajištěno, že všechny zprávy jsou nerozeznatelné od náhodných dat. To také vyžaduje, aby jejich délka byla náhodná, což je složitější než jen přidání náhodného paddingu. Ve skutečnosti v dodatku A autoři argumentují, že naivní (tj. uniformní) schéma paddingu problém neřeší. Dodatek A proto navrhuje zahrnout buď náhodná zpoždění nebo vyvinout alternativní schéma paddingu, které může poskytnout rozumnou ochranu proti navrhovanému útoku.
Jako ochranu proti šestému bodu výše by implementace měly zahrnovat náhodná zpoždění v protokolu. Takové techniky nejsou pokryty tímto návrhem, ale mohly by také vyřešit problémy s délkou paddingu. Shrnutí: návrh poskytuje dobrou ochranu proti analýze payload (když jsou vzaty v úvahu úvahy v Příloze A), ale pouze omezenou ochranu proti analýze toku.
2) Offline DPI
Offline DPI inspektující data uložená online DPI pro pozdější analýzu. Offline DPI může být navržena specificky pro detekci I2P. Offline DPI nemá přístup k síťové databázi I2P v reálném čase. Offline DPI má přístup k této i dalším I2P specifikacím. Offline DPI má neomezené výpočetní schopnosti, včetně všech kryptografických funkcí definovaných v této specifikaci.
Offline DPI nemá schopnost blokovat existující spojení. Offline DPI má schopnost provádět téměř v reálném čase (během minut od nastavení) odesílání na host/port účastníků, například TCP RST. Offline DPI má schopnost provádět téměř v reálném čase (během minut od nastavení) přehrávání předchozích zpráv (upravených či nikoliv) za účelem “sondování” nebo z jiných důvodů.
Není cílem zabránit identifikaci protokolu offline DPI. Veškeré dekódování zamaskovaných dat v prvních dvou zprávách, které je implementováno I2P routery, může být také implementováno offline DPI.
Cílem je zamítnout pokusy o připojení využívající opakování předchozích zpráv.
Future work
Zvažte chování protokolu, když jsou pakety zahozeny nebo změněno jejich pořadí útočníkem. Nedávnou zajímavou práci v této oblasti lze nalézt v IACR-1150.
Poskytovat přesnější klasifikaci systémů DPI s přihlédnutím k existující literatuře vztahující se k danému tématu.
Diskutujte o formální bezpečnosti navrhovaného protokolu, ideálně s ohledem na model útočníka pomocí DPI.
Noise Protocol Framework
Tento návrh poskytuje požadavky založené na Noise Protocol Framework NOISE (Revize 33, 2017-10-04). Noise má podobné vlastnosti jako protokol Station-To-Station, který je základem pro protokol SSU. V terminologii Noise je Alice iniciátor a Bob je respondent.
NTCP2 je založeno na Noise protokolu Noise_XK_25519_ChaChaPoly_SHA256. (Skutečný identifikátor pro počáteční funkci odvození klíče je “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256” pro označení I2P rozšíření - viz sekce KDF 1 níže) Tento Noise protokol používá následující primitiva:
Handshake Pattern: XK Alice předává svůj klíč Bobovi (X) Alice již zná Bobův statický klíč (K)
DH Function: X25519 X25519 DH s délkou klíče 32 bytů jak je specifikováno v RFC-7748.
Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305 jak je specifikováno v RFC-7539 sekce 2.8. 12 bajtový nonce, s prvními 4 bajty nastavenými na nulu.
Hash Function: SHA256 Standardní 32-bajtový hash, již hojně používaný v I2P.
Bezpečnostní cíle
Tento návrh definuje následující vylepšení pro Noise_XK_25519_ChaChaPoly_SHA256. Tyto obecně následují pokyny v sekci 13 NOISE.
Cleartext ephemeral klíče jsou zašifrovány pomocí AES šifrování s použitím známého klíče a IV. Toto je rychlejší než elligator2.
K zprávám 1 a 2 se přidává náhodné cleartext padding. Cleartext padding je zahrnuto do výpočtu hashe handshaku (MixHash). Viz sekce KDF níže pro zprávu 2 a zprávu 3 část 1. Náhodné AEAD padding se přidává ke zprávě 3 a zprávám datové fáze.
Přidává se dvoubajtové pole délky rámce, jak je vyžadováno pro Noise over TCP a stejně jako v obfs4. Toto se používá pouze ve zprávách datové fáze. AEAD rámce zpráv 1 a 2 mají pevnou délku. AEAD rámec zprávy 3 část 1 má pevnou délku. Délka AEAD rámce zprávy 3 část 2 je specifikována ve zprávě 1.
Dvoubytové pole délky rámce je zamaskováno pomocí SipHash-2-4, stejně jako v obfs4.
Formát payload je definován pro zprávy 1,2,3 a datovou fázi. To samozřejmě není definováno v Noise.
New Cryptographic Primitives for I2P
Stávající implementace I2P routerů budou vyžadovat implementace následujících standardních kryptografických primitiv, které nejsou vyžadovány pro současné I2P protokoly:
Generování klíčů X25519 a DH
AEAD_ChaCha20_Poly1305 (zkráceně jako ChaChaPoly níže)
SipHash-2-4
Processing overhead estimate
Velikosti zpráv pro 3 zprávy:
- 64 bajtů + padding (NTCP bylo 288 bajtů) 2) 64 bajtů + padding (NTCP bylo 304 bajtů) 3) přibližně 64 bajtů + Alice router info + padding Průměrné router info je asi 750 bajtů Celkem průměrně 814 bajtů před padding (NTCP bylo 448 bajtů) 4) není požadováno v NTCP2 (NTCP bylo 48 bajtů)
Celkem před paddingem: NTCP2: 942 bajtů NTCP: 1088 bajtů Všimněte si, že pokud se Alice připojila k Bobovi za účelem odeslání DatabaseStore zprávy se svými RouterInfo, tato zpráva není vyžadována, což ušetří přibližně 800 bajtů.
Následující kryptografické operace jsou vyžadovány každou stranou k dokončení handshake a zahájení datové fáze:
- AES: 2
- SHA256: 7 (Alice), 6 (Bob) (nezahrnuje 1 Alice, 2 Bob předpočítané pro všechna spojení) (nezahrnuje HMAC-SHA256)
- HMAC-SHA256: 19
- ChaChaPoly: 4
- X25519 generování klíčů: 1
- X25519 DH: 3
- Ověření podpisu: 1 (Bob) (Alice předtím podepsala při generování svého RI) Předpokládá se Ed25519 (závislé na typu podpisu RI)
Následující kryptografické operace jsou vyžadovány každou stranou pro každou zprávu datové fáze:
- SipHash: 1
- ChaChaPoly: 1
Messages
Všechny NTCP2 zprávy mají délku menší nebo rovnu 65537 bajtů. Formát zprávy je založen na Noise zprávách, s úpravami pro rámcování a nerozlišitelnost. Implementace používající standardní Noise knihovny možná budou muset předzpracovat přijaté zprávy do/z formátu Noise zpráv. Všechna šifrovaná pole jsou AEAD šifrotexty.
Sekvence navázání spojení je následující:
Alice Bob
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->
Při použití terminologie Noise je posloupnost navázání spojení a dat následující: (Vlastnosti zabezpečení užitečného zatížení)
XK(s, rs): Authentication Confidentiality
<- s
...
-> e, es 0 2
<- e, ee 2 1
-> s, se 2 5
<- 2 5
Jakmile je relace navázána, Alice a Bob si mohou vyměňovat zprávy Data.
Všechny typy zpráv (SessionRequest, SessionCreated, SessionConfirmed, Data a TimeSync) jsou specifikovány v této sekci.
Některé označení:
- RH_A = Router Hash pro Alice (32 bajtů)
- RH_B = Router Hash pro Boba (32 bajtů)
Authenticated Encryption
Existují tři samostatné instance autentizovaného šifrování (CipherStates). Jedna během fáze handshaku a dvě (odesílání a příjem) pro datovou fázi. Každá má svůj vlastní klíč z KDF.
Šifrovaná/autentizovaná data budou reprezentována jako
+----+----+----+----+----+----+----+----+
| |
+ +
| Encrypted and authenticated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Necíle
Šifrovaný a autentifikovaný formát dat.
Vstupy do funkcí šifrování/dešifrování:
k :: 32 byte cipher key, as generated from KDF
nonce :: Counter-based nonce, 12 bytes.
Starts at 0 and incremented for each message.
First four bytes are always zero.
Last eight bytes are the counter, little-endian encoded.
Maximum value is 2**64 - 2.
Connection must be dropped and restarted after
it reaches that value.
The value 2**64 - 1 must never be sent.
ad :: In handshake phase:
Associated data, 32 bytes.
The SHA256 hash of all preceding data.
In data phase:
Zero bytes
data :: Plaintext data, 0 or more bytes
Výstup funkce šifrování, vstup do funkce dešifrování:
+----+----+----+----+----+----+----+----+
|Obfs Len | |
+----+----+ +
| ChaCha20 encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) +
| 16 bytes |
+----+----+----+----+----+----+----+----+
Obfs Len :: Length of (encrypted data + MAC) to follow, 16 - 65535
Obfuscation using SipHash (see below)
Not used in message 1 or 2, or message 3 part 1, where the length is fixed
Not used in message 3 part 1, as the length is specified in message 1
encrypted data :: Same size as plaintext data, 0 - 65519 bytes
MAC :: Poly1305 message authentication code, 16 bytes
Pro ChaCha20 odpovídá to, co je zde popsáno, RFC-7539, které je také podobně používáno v TLS RFC-7905.
Notes
Jelikož ChaCha20 je proudová šifra, plaintexty nemusí být doplněny. Dodatečné bajty keystream jsou zahozeny.
Klíč pro šifru (256 bitů) je dohodnut prostřednictvím SHA256 KDF. Podrobnosti KDF pro každou zprávu jsou uvedeny v samostatných sekcích níže.
ChaChaPoly rámce pro zprávy 1, 2 a první část zprávy 3 mají známou velikost. Počínaje druhou částí zprávy 3 mají rámce proměnnou velikost. Velikost části 1 zprávy 3 je specifikována ve zprávě 1. Počínaje datovou fází jsou rámce předřazeny dvoubajtovou délkou zamaskovanou pomocí SipHash jako v obfs4.
Padding je mimo rámec autentifikovaných dat pro zprávy 1 a 2. Padding se používá v KDF pro následující zprávu, takže manipulace bude detekována. Počínaje zprávou 3 je padding uvnitř rámce autentifikovaných dat.
Související cíle
Ve zprávách 1, 2 a ve zprávě 3 částech 1 a 2 je velikost AEAD zprávy známa předem. Při selhání AEAD autentizace musí příjemce zastavit další zpracování zpráv a uzavřít spojení bez odpovědi. Toto by mělo být neobvyklé uzavření (TCP RST).
Pro odolnost proti sondování by měl Bob ve zprávě 1 po selhání AEAD nastavit náhodný timeout (rozsah bude určen) a poté přečíst náhodný počet bytů (rozsah bude určen) před zavřením socketu. Bob by měl udržovat blacklist IP adres s opakovanými selháními.
Ve fázi dat je velikost AEAD zprávy “zašifrována” (zamaskována) pomocí SipHash. Je třeba dbát na to, aby nedošlo k vytvoření decryption oracle. Při selhání AEAD autentifikace ve fázi dat by příjemce měl nastavit náhodný timeout (rozsah TBD) a poté přečíst náhodný počet bajtů (rozsah TBD). Po přečtení nebo při timeoutu čtení by příjemce měl odeslat payload s termination blokem obsahujícím kód důvodu “AEAD failure” a uzavřít spojení.
Proveďte stejnou chybovou akci pro neplatnou hodnotu pole délky ve fázi dat.
Key Derivation Function (KDF) (for handshake message 1)
KDF generuje klíč k pro šifrování fáze handshake z DH výsledku, používá HMAC-SHA256(key, data) jak je definováno v RFC-2104. Jedná se o funkce InitializeSymmetric(), MixHash() a MixKey(), přesně jak jsou definovány ve specifikaci Noise.
This is the "e" message pattern:
// Define protocol_name.
Set protocol_name = "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"
(48 bytes, US-ASCII encoded, no NULL termination).
// Define Hash h = 32 bytes
h = SHA256(protocol_name);
Define ck = 32 byte chaining key. Copy the h data to ck.
Set ck = h
Define rs = Bob's 32-byte static key as published in the RouterInfo
// MixHash(null prologue)
h = SHA256(h);
// up until here, can all be precalculated by Alice for all outgoing connections
// Alice must validate that Bob's static key is a valid point on the curve here.
// Bob static key
// MixHash(rs)
// || below means append
h = SHA256(h || rs);
// up until here, can all be precalculated by Bob for all incoming connections
This is the "e" message pattern:
Alice generates her ephemeral DH key pair e.
// Alice ephemeral key X
// MixHash(e.pubkey)
// || below means append
h = SHA256(h || e.pubkey);
// h is used as the associated data for the AEAD in message 1
// Retain the Hash h for the message 2 KDF
End of "e" message pattern.
This is the "es" message pattern:
// DH(e, rs) == DH(s, re)
Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's static key
Set input_key_material = X25519 DH result
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, defined above
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
// retain the chaining key ck for message 2 KDF
End of "es" message pattern.
Další diskuze o DPI
Alice posílá Bobovi.
Noise obsah: Alice’s ephemeral key X Noise payload: 16 byte option block Non-noise payload: Náhodné vyplnění
(Vlastnosti zabezpečení datové části)
XK(s, rs): Authentication Confidentiality
-> e, es 0 2
Authentication: None (0).
This payload may have been sent by any party, including an active attacker.
Confidentiality: 2.
Encryption to a known recipient, forward secrecy for sender compromise
only, vulnerable to replay. This payload is encrypted based only on DHs
involving the recipient's static key pair. If the recipient's static
private key is compromised, even at a later date, this payload can be
decrypted. This message can also be replayed, since there's no ephemeral
contribution from the recipient.
"e": Alice generates a new ephemeral key pair and stores it in the e
variable, writes the ephemeral public key as cleartext into the
message buffer, and hashes the public key along with the old h to
derive a new h.
"es": A DH is performed between the Alice's ephemeral key pair and the
Bob's static key pair. The result is hashed along with the old ck to
derive a new ck and k, and n is set to zero.
Hodnota X je šifrována pro zajištění nerozlišitelnosti a jedinečnosti užitečného zatížení, což jsou nezbytná opatření proti DPI. K dosažení tohoto cíle používáme šifrování AES, spíše než složitější a pomalejší alternativy jako je elligator2. Asymetrické šifrování k veřejnému klíči Bobova routeru by bylo příliš pomalé. Šifrování AES používá hash Bobova routeru jako klíč a Bobův IV jak je publikován v síťové databázi.
AES šifrování slouží pouze k odolnosti proti DPI. Jakákoli strana znající Bobův router hash a IV, které jsou publikovány v síťové databázi, může dešifrovat hodnotu X v této zprávě.
Padding není šifrován Alicí. Může být nutné, aby Bob dešifroval padding, aby zabránil časovým útokům.
Nezpracovaný obsah:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| ChaChaPoly frame |
+ (32 bytes) +
| k defined in KDF for message 1 |
+ n = 0 +
| see KDF for associated data |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
~ padding (optional) ~
| length defined in options block |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
key: RH_B
iv: As published in Bobs network database entry
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Total message length must be 287 bytes or less if
Bob is publishing his address as NTCP
(see Version Detection section below).
Alice and Bob will use the padding data in the KDF for message 2.
It is authenticated so that any tampering will cause the
next message to fail.
Nešifrovaná data (Poly1305 autentizační tag není zobrazen):
+----+----+----+----+----+----+----+----+
| |
+ +
| X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, X25519 ephemeral key, little endian
options :: options block, 16 bytes, see below
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Total message length must be 287 bytes or less if
Bob is publishing his address as "NTCP"
(see Version Detection section below)
Alice and Bob will use the padding data in the KDF for message 2.
It is authenticated so that any tampering will cause the
next message to fail.
Blok možností: Poznámka: Všechna pole jsou v big-endian formátu.
+----+----+----+----+----+----+----+----+
| id | ver| padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
| tsA | Reserved (0) |
+----+----+----+----+----+----+----+----+
id :: 1 byte, the network ID (currently 2, except for test networks)
As of 0.9.42. See proposal 147.
ver :: 1 byte, protocol version (currently 2)
padLen :: 2 bytes, length of the padding, 0 or more
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.)
m3p2Len :: 2 bytes, length of the the second AEAD frame in SessionConfirmed
(message 3 part 2) See notes below
Rsvd :: 2 bytes, set to 0 for compatibility with future options
tsA :: 4 bytes, Unix timestamp, unsigned seconds.
Wraps around in 2106
Reserved :: 4 bytes, set to 0 for compatibility with future options
Notes
Když je publikovaná adresa “NTCP”, Bob podporuje jak NTCP, tak NTCP2 na stejném portu. Kvůli kompatibilitě musí Alice při navazování spojení na adresu publikovanou jako “NTCP” omezit maximální velikost této zprávy, včetně paddingu, na 287 bajtů nebo méně. To usnadňuje automatickou identifikaci protokolu ze strany Boba. Když je publikováno jako “NTCP2”, neexistuje žádné omezení velikosti. Viz sekce Publikované adresy a Detekce verzí níže.
Jedinečná hodnota X v počátečním AES bloku zajišťuje, že šifrovaný text je odlišný pro každou relaci.
Bob musí odmítnout spojení, kde je hodnota časové značky příliš vzdálená od aktuálního času. Nazvěme maximální časový rozdíl “D”. Bob musí udržovat místní cache dříve použitých handshake hodnot a odmítat duplikáty, aby zabránil replay útokům. Hodnoty v cache musí mít životnost nejméně 2*D. Hodnoty cache jsou závislé na implementaci, nicméně lze použít 32-bytovou hodnotu X (nebo její šifrovaný ekvivalent).
Diffie-Hellman dočasné klíče nesmí být nikdy znovu použity, aby se předešlo kryptografickým útokům, a opětovné použití bude odmítnuto jako replay útok.
Možnosti “KE” a “auth” musí být kompatibilní, tj. sdílené tajemství K musí mít odpovídající velikost. Pokud budou přidány další možnosti “auth”, mohlo by to implicitně změnit význam příznaku “KE” tak, aby používal jiný KDF nebo jinou velikost zkrácení.
Bob musí ověřit, že Alicin dočasný klíč je platný bod na křivce zde.
Padding by měl být omezen na rozumné množství. Bob může odmítnout spojení s nadměrným paddingem. Bob specifikuje své možnosti paddingu ve zprávě 2. Směrnice pro min/max TBD. Náhodná velikost od 0 do 31 bajtů minimálně? (Distribuce bude určena, viz Příloha A.)
Při jakékoli chybě, včetně AEAD, DH, časové značky, zjevného replay útoku nebo selhání validace klíče, musí Bob zastavit další zpracování zpráv a uzavřít spojení bez odpovědi. Toto by mělo být abnormální ukončení (TCP RST). Pro odolnost proti sondování by měl Bob po selhání AEAD nastavit náhodný timeout (rozsah TBD) a poté přečíst náhodný počet bajtů (rozsah TBD), před uzavřením socketu.
Zmírnění DoS: DH je relativně nákladná operace. Stejně jako u předchozího protokolu NTCP by routery měly přijmout všechna nezbytná opatření k zabránění vyčerpání CPU nebo připojení. Nastavte limity na maximální aktivní připojení a maximální počet probíhajících nastavení připojení. Vynuťte časové limity pro čtení (jak per-read, tak celkové pro “slowloris”). Omezte opakovaná nebo současná připojení ze stejného zdroje. Udržujte černé listiny pro zdroje, které opakovaně selhávají. Nereagujte na selhání AEAD.
Pro usnadnění rychlé detekce verze a handshakingu musí implementace zajistit, aby Alice uložila do bufferu a poté odeslala celý obsah první zprávy najednou, včetně paddingu. To zvyšuje pravděpodobnost, že data budou obsažena v jediném TCP paketu (pokud nebudou segmentována OS nebo middleboxy) a budou přijata Bobem najednou. Navíc musí implementace zajistit, aby Bob uložil do bufferu a poté odeslal celý obsah druhé zprávy najednou, včetně paddingu, a aby Bob uložil do bufferu a poté odeslal celý obsah třetí zprávy najednou. To je také kvůli efektivitě a k zajištění účinnosti náhodného paddingu.
“ver” pole: Celkový Noise protokol, rozšíření a NTCP protokol včetně specifikací payload, indikující NTCP2. Toto pole může být použito k indikaci podpory budoucích změn.
Message 3 part 2 length: Toto je velikost druhého AEAD rámce (včetně 16-bajtového MAC) obsahujícího Router Info od Alice a volitelné padding, který bude odeslán ve zprávě SessionConfirmed. Jelikož routery periodicky regenerují a znovu publikují své Router Info, velikost aktuálního Router Info se může změnit před odesláním zprávy 3. Implementace musí zvolit jednu ze dvou strategií: a) uložit aktuální Router Info k odeslání ve zprávě 3, aby byla velikost známa, a volitelně přidat místo pro padding; b) zvýšit specifikovanou velikost dostatečně, aby umožnila možné zvětšení velikosti Router Info, a vždy přidat padding při skutečném odeslání zprávy 3. V obou případech musí délka “m3p2len” zahrnutá ve zprávě 1 přesně odpovídat velikosti daného rámce při odeslání ve zprávě 3.
Bob musí ukončit spojení s chybou, pokud po validaci zprávy 1 a přečtení paddingu zůstanou nějaká příchozí data. Neměla by existovat žádná extra data od Alice, protože Bob ještě neodpověděl zprávou 2.
Pole network ID se používá k rychlé identifikaci připojení napříč sítěmi. Pokud je toto pole nenulové a neodpovídá Bobovu network ID, Bob by se měl odpojit a blokovat budoucí připojení. Od verze 0.9.42. Viz proposal 147 pro více informací.
Key Derivation Function (KDF) (for handshake message 2 and message 3 part 1)
// take h saved from message 1 KDF
// MixHash(ciphertext)
h = SHA256(h || 32 byte encrypted payload from message 1)
// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 1)
This is the "e" message pattern:
Bob generates his ephemeral DH key pair e.
// h is from KDF for handshake message 1
// Bob ephemeral key Y
// MixHash(e.pubkey)
// || below means append
h = SHA256(h || e.pubkey);
// h is used as the associated data for the AEAD in message 2
// Retain the Hash h for the message 3 KDF
End of "e" message pattern.
This is the "ee" message pattern:
// DH(e, re)
Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Alice's ephemeral key in memory, no longer needed
// Alice:
e(public and private) = (all zeros)
// Bob:
re = (all zeros)
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
// retain the chaining key ck for message 3 KDF
End of "ee" message pattern.
2) SessionCreated
Bob posílá Alici.
Noise obsah: Bobův efemérní klíč Y Noise payload: 16bajtový blok možností Non-noise payload: Náhodné vyplnění
(Vlastnosti zabezpečení datové části)
XK(s, rs): Authentication Confidentiality
<- e, ee 2 1
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI).
The sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key pair.
Assuming the corresponding private keys are secure, this authentication cannot be forged.
Confidentiality: 1.
Encryption to an ephemeral recipient.
This payload has forward secrecy, since encryption involves an ephemeral-ephemeral DH ("ee").
However, the sender has not authenticated the recipient,
so this payload might be sent to any party, including an active attacker.
"e": Bob generates a new ephemeral key pair and stores it in the e variable,
writes the ephemeral public key as cleartext into the message buffer,
and hashes the public key along with the old h to derive a new h.
"ee": A DH is performed between the Bob's ephemeral key pair and the Alice's ephemeral key pair.
The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.
Hodnota Y je šifrována pro zajištění nerozlišitelnosti a jedinečnosti payload, které jsou nezbytné jako protiopatření proti DPI. K dosažení tohoto používáme AES šifrování místo složitějších a pomalejších alternativ jako je elligator2. Asymetrické šifrování na veřejný klíč Alice routeru by bylo příliš pomalé. AES šifrování používá hash Bobova routeru jako klíč a AES stav ze zprávy 1 (který byl inicializován s Bobovým IV publikovaným v síťové databázi).
AES šifrování slouží pouze k odolnosti proti DPI. Jakákoli strana, která zná Bobův router hash a IV, které jsou publikovány v síťové databázi, a zachytí prvních 32 bajtů zprávy 1, může dešifrovat hodnotu Y v této zprávě.
Surový obsah:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ChaChaPoly frame |
+ Encrypted and authenticated data +
| 32 bytes |
+ k defined in KDF for message 2 +
| n = 0; see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
key: RH_B
iv: Using AES state from message 1
Nešifrovaná data (Poly1305 autentifikační značka není zobrazena):
+----+----+----+----+----+----+----+----+
| |
+ +
| Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, X25519 ephemeral key, little endian
options :: options block, 16 bytes, see below
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Alice and Bob will use the padding data in the KDF for message 3 part 1.
It is authenticated so that any tampering will cause the
next message to fail.
Notes
Alice musí zde ověřit, že Bobův dočasný klíč je platný bod na křivce.
Padding by měl být omezen na rozumné množství. Alice může odmítnout spojení s nadměrným paddingem. Alice určí své možnosti paddingu ve zprávě 3. Doporučení pro min/max TBD. Náhodná velikost od 0 do 31 bajtů minimum? (Distribuce bude určena, viz Příloha A.)
Při jakékoli chybě, včetně AEAD, DH, časového razítka, zjevného replay útoku nebo selhání validace klíče, musí Alice zastavit další zpracování zpráv a uzavřít spojení bez odpovědi. Toto by mělo být abnormální uzavření (TCP RST).
Pro usnadnění rychlého handshakingu musí implementace zajistit, že Bob uloží do bufferu a poté vyprázdní celý obsah první zprávy najednou, včetně paddingu. To zvyšuje pravděpodobnost, že data budou obsažena v jediném TCP paketu (pokud nebudou segmentována OS nebo middleboxy) a Alice je přijme najednou. To je také kvůli efektivitě a zajištění účinnosti náhodného paddingu.
Alice musí ukončit spojení s chybou, pokud po validaci zprávy 2 a načtení paddingu zůstávají nějaká příchozí data. Neměla by existovat žádná další data od Boba, protože Alice ještě neodpověděla zprávou 3.
Blok možností: Poznámka: Všechna pole jsou big-endian.
+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen | Reserved (0) |
+----+----+----+----+----+----+----+----+
| tsB | Reserved (0) |
+----+----+----+----+----+----+----+----+
Reserved :: 10 bytes total, set to 0 for compatibility with future options
padLen :: 2 bytes, big endian, length of the padding, 0 or more
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.)
tsB :: 4 bytes, big endian, Unix timestamp, unsigned seconds.
Wraps around in 2106
Notes
- Alice musí odmítnout připojení, kde je hodnota časového razítka příliš vzdálená od aktuálního času. Maximální časový rozdíl označme jako “D”. Alice musí udržovat lokální cache dříve použitých handshake hodnot a odmítat duplikáty, aby zabránila replay útokům. Hodnoty v cache musí mít životnost alespoň 2*D. Cache hodnoty jsou závislé na implementaci, nicméně může být použita 32-bajtová hodnota Y (nebo její šifrovaný ekvivalent).
Issues
- Zahrnout zde možnosti min/max padding?
Encryption for for handshake message 3 part 1, using message 2 KDF)
// take h saved from message 2 KDF
// MixHash(ciphertext)
h = SHA256(h || 24 byte encrypted payload from message 2)
// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 2)
// h is used as the associated data for the AEAD in message 3 part 1, below
This is the "s" message pattern:
Define s = Alice's static public key, 32 bytes
// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// k is from handshake message 1
// n is 1
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);
// h is used as the associated data for the AEAD in message 3 part 2
End of "s" message pattern.
Key Derivation Function (KDF) (for handshake message 3 part 2)
This is the "se" message pattern:
// DH(s, re) == DH(e, rs)
Define input_key_material = 32 byte DH result of Alice's static key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Bob's ephemeral key in memory, no longer needed
// Alice:
re = (all zeros)
// Bob:
e(public and private) = (all zeros)
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// h from message 3 part 1 is used as the associated data for the AEAD in message 3 part 2
// EncryptAndHash(payload)
// EncryptWithAd(h, payload)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// n is 0
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, payload)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);
// retain the chaining key ck for the data phase KDF
// retain the hash h for the data phase Additional Symmetric Key (SipHash) KDF
End of "se" message pattern.
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
3) SessionConfirmed
Alice posílá Bobovi.
Noise obsah: Alice’s static key Noise payload: Alice’s RouterInfo a náhodné vyplnění Non-noise payload: žádný
(Vlastnosti zabezpečení dat)
XK(s, rs): Authentication Confidentiality
-> s, se 2 5
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI). The
sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key
pair. Assuming the corresponding private keys are secure, this
authentication cannot be forged.
Confidentiality: 5.
Encryption to a known recipient, strong forward secrecy. This payload is
encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
DH with the recipient's static key pair. Assuming the ephemeral private
keys are secure, and the recipient is not being actively impersonated by an
attacker that has stolen its static private key, this payload cannot be
decrypted.
"s": Alice writes her static public key from the s variable into the
message buffer, encrypting it, and hashes the output along with the old h
to derive a new h.
"se": A DH is performed between the Alice's static key pair and the Bob's
ephemeral key pair. The result is hashed along with the old ck to derive a
new ck and k, and n is set to zero.
Toto obsahuje dva ChaChaPoly rámce. První je Alice zašifrovaný statický veřejný klíč. Druhý je Noise payload: Alice zašifrovaný RouterInfo, volitelné možnosti a volitelné padding. Používají různé klíče, protože mezi nimi je volána funkce MixKey().
Nezpracovaný obsah:
+----+----+----+----+----+----+----+----+
| |
+ ChaChaPoly frame (48 bytes) +
| Encrypted and authenticated |
+ Alice static key S +
| (32 bytes) |
+ +
| k defined in KDF for message 2 |
+ n = 1 +
| see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ Length specified in message 1 +
| |
+ ChaChaPoly frame +
| Encrypted and authenticated |
+ +
| Alice RouterInfo |
+ using block format 2 +
| Alice Options (optional) |
+ using block format 1 +
| Arbitrary padding |
+ using block format 254 +
| |
+ +
| k defined in KDF for message 3 part 2 |
+ n = 0 +
| see KDF for associated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little endian
inside 48 byte ChaChaPoly frame
Nešifrovaná data (Poly1305 autentizační značky nejsou zobrazeny):
+----+----+----+----+----+----+----+----+
| |
+ +
| S |
+ Alice static key +
| (32 bytes) |
+ +
| |
+ +
+----+----+----+----+----+----+----+----+
| |
+ +
| |
+ +
| Alice RouterInfo block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Options block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Padding block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, Alice's X25519 static key, little endian
1) Online DPI
Bob musí provést obvyklou validaci Router Info. Ujistit se, že typ podpisu je podporován, ověřit podpis, ověřit, že časové razítko je v mezích, a jakékoli další potřebné kontroly.
Bob musí ověřit, že Alicin statický klíč obdržený v prvním rámci odpovídá statickému klíči v Router Info. Bob musí nejprve vyhledat v Router Info NTCP nebo NTCP2 Router Address s odpovídající opcí verze (v). Viz sekce Publikované Router Info a Nepublikované Router Info níže.
Pokud má Bob starší verzi RouterInfo Alice ve svém netdb, ověřte, že statický klíč v router info je stejný v obou, pokud je přítomen, a pokud je starší verze méně než XXX stará (viz čas rotace klíče níže)
Bob musí zde ověřit, že Alicin statický klíč je platný bod na křivce.
Možnosti by měly být zahrnuty pro specifikaci parametrů padding.
Při jakékoliv chybě, včetně selhání validace AEAD, RI, DH, časové značky nebo klíče, musí Bob zastavit další zpracování zpráv a uzavřít spojení bez odpovědi. Toto by mělo být abnormální uzavření (TCP RST).
Pro usnadnění rychlého handshakingu musí implementace zajistit, že Alice ukládá do bufferu a poté vyprázdní celý obsah třetí zprávy najednou, včetně obou AEAD rámců. To zvyšuje pravděpodobnost, že data budou obsažena v jediném TCP paketu (pokud nebudou segmentována OS nebo middleboxy) a Bob je přijme najednou. To je také kvůli efektivitě a k zajištění účinnosti náhodného paddingu.
Message 3 part 2 frame length: Délka tohoto rámce (včetně MAC) je odeslána Alicí ve zprávě 1. Viz tuto zprávu pro důležité poznámky o ponechání dostatečného místa pro padding.
Message 3 část 2 obsah rámce: Formát tohoto rámce je stejný jako formát rámců datové fáze, kromě toho, že délka rámce je odeslána Alice ve zprávě 1. Viz níže pro formát rámce datové fáze. Rámec musí obsahovat 1 až 3 bloky v následujícím pořadí:
- Blok Router Info Alice (povinný)
- Blok možností (volitelný)
- Blok výplně (volitelný) Tento rámec nesmí nikdy obsahovat žádný jiný typ bloku.
Padding druhé části zprávy 3 není vyžadován, pokud Alice připojí rámec datové fáze (volitelně obsahující padding) na konec zprávy 3 a odešle obě najednou, protože pozorovateli to bude vypadat jako jeden velký proud bajtů. Jelikož Alice obecně, ale ne vždy, bude mít I2NP zprávu k odeslání Bobovi (proto se k němu připojila), jedná se o doporučenou implementaci, kvůli efektivitě a k zajištění účinnosti náhodného paddingu.
Celková délka obou AEAD framů zprávy 3 (části 1 a 2) je 65535 bajtů; část 1 má 48 bajtů, takže maximální délka framu části 2 je 65487; maximální délka plaintextu části 2 bez MAC je 65471.
Key Derivation Function (KDF) (for data phase)
Datová fáze používá vstup přidružených dat o nulové délce.
KDF generuje dva šifrovací klíče k_ab a k_ba z řetězového klíče ck, pomocí HMAC-SHA256(key, data) jak je definováno v RFC-2104. Toto je funkce Split(), přesně jak je definována ve specifikaci Noise.
ck = from handshake phase
// k_ab, k_ba = HKDF(ck, zerolen)
// ask_master = HKDF(ck, zerolen, info="ask")
// zerolen is a zero-length byte array
temp_key = HMAC-SHA256(ck, zerolen)
// overwrite the chaining key in memory, no longer needed
ck = (all zeros)
// Output 1
// cipher key, for Alice transmits to Bob (Noise doesn't make clear which is which, but Java code does)
k_ab = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// cipher key, for Bob transmits to Alice (Noise doesn't make clear which is which, but Java code does)
k_ba = HMAC-SHA256(temp_key, k_ab || byte(0x02)).
KDF for SipHash for length field:
Generate an Additional Symmetric Key (ask) for SipHash
SipHash uses two 8-byte keys (big endian) and 8 byte IV for first data.
// "ask" is 3 bytes, US-ASCII, no null termination
ask_master = HMAC-SHA256(temp_key, "ask" || byte(0x01))
// sip_master = HKDF(ask_master, h || "siphash")
// "siphash" is 7 bytes, US-ASCII, no null termination
// overwrite previous temp_key in memory
// h is from KDF for message 3 part 2
temp_key = HMAC-SHA256(ask_master, h || "siphash")
// overwrite ask_master in memory, no longer needed
ask_master = (all zeros)
sip_master = HMAC-SHA256(temp_key, byte(0x01))
Alice to Bob SipHash k1, k2, IV:
// sipkeys_ab, sipkeys_ba = HKDF(sip_master, zerolen)
// overwrite previous temp_key in memory
temp_key = HMAC-SHA256(sip_master, zerolen)
// overwrite sip_master in memory, no longer needed
sip_master = (all zeros)
sipkeys_ab = HMAC-SHA256(temp_key, byte(0x01)).
sipk1_ab = sipkeys_ab[0:7], little endian
sipk2_ab = sipkeys_ab[8:15], little endian
sipiv_ab = sipkeys_ab[16:23]
Bob to Alice SipHash k1, k2, IV:
sipkeys_ba = HMAC-SHA256(temp_key, sipkeys_ab || byte(0x02)).
sipk1_ba = sipkeys_ba[0:7], little endian
sipk2_ba = sipkeys_ba[8:15], little endian
sipiv_ba = sipkeys_ba[16:23]
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
4) Data Phase
Noise payload: Jak je definováno níže, včetně náhodného paddingu Non-noise payload: žádný
Počínaje 2. částí zprávy 3 jsou všechny zprávy uvnitř autentifikovaného a šifrovaného ChaChaPoly “rámce” s předřazenou dvoubajtovou zamaskovanou délkou. Veškeré vyplňování je uvnitř rámce. Uvnitř rámce je standardní formát s nula nebo více “bloky”. Každý blok má jednobajtový typ a dvoubajtovou délku. Typy zahrnují datum/čas, I2NP zprávu, možnosti, ukončení a vyplňování.
Poznámka: Bob může, ale není povinen, poslat své RouterInfo Alici jako svou první zprávu Alici ve fázi dat.
(Bezpečnostní vlastnosti datové části)
XK(s, rs): Authentication Confidentiality
<- 2 5
-> 2 5
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI).
The sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key pair.
Assuming the corresponding private keys are secure, this authentication cannot be forged.
Confidentiality: 5.
Encryption to a known recipient, strong forward secrecy.
This payload is encrypted based on an ephemeral-ephemeral DH as well as
an ephemeral-static DH with the recipient's static key pair.
Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated
by an attacker that has stolen its static private key, this payload cannot be decrypted.
2) Offline DPI
Pro efektivitu a pro minimalizaci identifikace pole délky musí implementace zajistit, že odesílatel ukládá do vyrovnávací paměti a poté vyprázdní celý obsah datových zpráv najednou, včetně pole délky a AEAD rámce. To zvyšuje pravděpodobnost, že data budou obsažena v jediném TCP paketu (pokud nebudou segmentována operačním systémem nebo middleboxy) a přijata najednou druhou stranou. To je také kvůli efektivitě a pro zajištění účinnosti náhodného paddingu.
Router může zvolit ukončení relace při AEAD chybě, nebo může pokračovat v pokusech o komunikaci. Pokud pokračuje, router by měl ukončit spojení po opakovaných chybách.
SipHash obfuscated length
Reference: SipHash
Jakmile obě strany dokončí handshake, přenášejí payloady, které jsou následně šifrovány a autentizovány v ChaChaPoly “rámcích”.
Každý rámec je předcházen dvoubajtovou délkou v big endian pořadí. Tato délka specifikuje počet šifrovaných bajtů rámce, které následují, včetně MAC. Aby se předešlo přenosu identifikovatelných polí délky v proudu, délka rámce je obfuskována XOR operací s maskou odvozenou ze SipHash, jak je inicializována z data phase KDF. Poznámka: oba směry mají jedinečné SipHash klíče a IV z KDF.
sipk1, sipk2 = The SipHash keys from the KDF. (two 8-byte long integers)
IV[0] = sipiv = The SipHash IV from the KDF. (8 bytes)
length is big endian.
For each frame:
IV[n] = SipHash-2-4(sipk1, sipk2, IV[n-1])
Mask[n] = First 2 bytes of IV[n]
obfuscatedLength = length ^ Mask[n]
The first length output will be XORed with with IV[1].
Příjemce má identické SipHash klíče a IV. Dekódování délky se provádí odvozením masky použité k zamlžení délky a XOR operací zkráceného hashe pro získání délky rámce. Délka rámce je celková délka šifrovaného rámce včetně MAC.
Budoucí práce
- Pokud používáte funkci knihovny SipHash, která vrací unsigned long integer, použijte nejméně významné dva bajty jako Mask. Převeďte long integer na další IV jako little endian.
Ověřená šifrování
+----+----+----+----+----+----+----+----+
|obf size | |
+----+----+ +
| |
+ ChaChaPoly frame +
| Encrypted and authenticated |
+ key is k_ab for Alice to Bob +
| key is k_ba for Bob to Alice |
+ as defined in KDF for data phase +
| n starts at 0 and increments |
+ for each frame in that direction +
| no associated data |
+ 16 bytes minimum +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
obf size :: 2 bytes length obfuscated with SipHash
when de-obfuscated: 16 - 65535
Minimum size including length field is 18 bytes.
Maximum size including length field is 65537 bytes.
Obfuscated length is 2 bytes.
Maximum ChaChaPoly frame is 65535 bytes.
ChaCha20/Poly1305
V šifrovaném rámci je nula nebo více bloků. Každý blok obsahuje jednobytový identifikátor, dvojbytovou délku a nula nebo více bajtů dat.
Pro rozšiřitelnost musí příjemci ignorovat bloky s neznámými identifikátory a zacházet s nimi jako s výplní.
Šifrovaná data mají maximálně 65535 bajtů, včetně 16-bajtové autentizační hlavičky, takže maximum nešifrovaných dat je 65519 bajtů.
(Poly1305 autentizační tag není zobrazen):
+----+----+----+----+----+----+----+----+
|blk | size | data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
|blk | size | data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
~ . . . ~
blk :: 1 byte
0 for datetime
1 for options
2 for RouterInfo
3 for I2NP message
4 for termination
224-253 reserved for experimental features
254 for padding
255 reserved for future extension
size :: 2 bytes, big endian, size of data to follow, 0 - 65516
data :: the data
Maximum ChaChaPoly frame is 65535 bytes.
Poly1305 tag is 16 bytes
Maximum total block size is 65519 bytes
Maximum single block size is 65519 bytes
Block type is 1 byte
Block length is 2 bytes
Maximum single block data size is 65516 bytes.
Block Ordering Rules
Ve zprávě handshake 3 část 2 musí být pořadí: RouterInfo, následované Options pokud jsou přítomny, následované Padding pokud je přítomno. Žádné jiné bloky nejsou povoleny.
Ve fázi dat není pořadí specifikováno, kromě následujících požadavků: Padding, pokud je přítomen, musí být posledním blokem. Termination, pokud je přítomna, musí být posledním blokem kromě Padding.
V jednom rámci může být více I2NP bloků. Více bloků Padding není v jednom rámci povoleno. Ostatní typy bloků pravděpodobně nebudou mít více bloků v jednom rámci, ale není to zakázáno.
Zpracování chyb AEAD
Speciální případ pro synchronizaci času:
+----+----+----+----+----+----+----+
| 0 | 4 | timestamp |
+----+----+----+----+----+----+----+
blk :: 0
size :: 2 bytes, big endian, value = 4
timestamp :: Unix timestamp, unsigned seconds.
Wraps around in 2106
Funkce odvození klíče (KDF) (pro handshake zprávu 1)
Předat aktualizované možnosti. Možnosti zahrnují: Minimální a maximální padding.
Blok možností bude mít proměnnou délku.
+----+----+----+----+----+----+----+----+
| 1 | size |tmin|tmax|rmin|rmax|tdmy|
+----+----+----+----+----+----+----+----+
|tdmy| rdmy | tdelay | rdelay | |
~----+----+----+----+----+----+----+ ~
| more_options |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 1
size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum
tmin, tmax, rmin, rmax :: requested padding limits
tmin and rmin are for desired resistance to traffic analysis.
tmax and rmax are for bandwidth limits.
tmin and tmax are the transmit limits for the router sending this options block.
rmin and rmax are the receive limits for the router sending this options block.
Each is a 4.4 fixed-point float representing 0 to 15.9375
(or think of it as an unsigned 8-bit integer divided by 16.0).
This is the ratio of padding to data. Examples:
Value of 0x00 means no padding
Value of 0x01 means add 6 percent padding
Value of 0x10 means add 100 percent padding
Value of 0x80 means add 800 percent (8x) padding
Alice and Bob will negotiate the minimum and maximum in each direction.
These are guidelines, there is no enforcement.
Sender should honor receiver's maximum.
Sender may or may not honor receiver's minimum, within bandwidth constraints.
tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
rdelay: Requested intra-message delay, 2 bytes big endian, msec average
Padding distribution specified as additional parameters?
Random delay specified as additional parameters?
more_options :: Format TBD
1) SessionRequest
- Formát možností je TBD.
- Vyjednávání možností je TBD.
RouterInfo
Předej RouterInfo Alice Bobovi. Používá se ve zprávě handshake 3 část 2. Předej RouterInfo Alice Bobovi, nebo Bobovo Alici. Používá se volitelně v datové fázi.
+----+----+----+----+----+----+----+----+
| 2 | size |flg | RouterInfo |
+----+----+----+----+ +
| (Alice RI in handshake msg 3 part 2) |
~ (Alice, Bob, or third-party ~
| RI in data phase) |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 2
size :: 2 bytes, big endian, size of flag + router info to follow
flg :: 1 byte flags
bit order: 76543210
bit 0: 0 for local store, 1 for flood request
bits 7-1: Unused, set to 0 for future compatibility
routerinfo :: Alice's or Bob's RouterInfo
Notes
Při použití ve fázi dat musí příjemce (Alice nebo Bob) ověřit, že se jedná o stejný Router Hash, který byl původně odeslán (pro Alice) nebo poslán (pro Boba). Poté s ním zacházet jako s lokální I2NP DatabaseStore Message. Ověřit podpis, ověřit novější časové razítko a uložit do lokální netdb. Pokud je flag bit 0 roven 1 a přijímající strana je floodfill, zacházet s ní jako s DatabaseStore Message s nenulovým reply tokenem a zaplavit ji do nejbližších floodfillů.
Router Info NENÍ komprimována pomocí gzip (na rozdíl od DatabaseStore zprávy, kde je)
Flooding nesmí být vyžádán, pokud neexistují publikované RouterAddresses v RouterInfo. Přijímající router nesmí flooding RouterInfo provádět, pokud v něm nejsou publikované RouterAddresses.
Implementátoři musí zajistit, že při čtení bloku nesprávně formátovaná nebo škodlivá data nezpůsobí, že čtení přesáhne do následujícího bloku.
Tento protokol neposkytuje potvrzení, že RouterInfo byla přijata, uložena nebo rozšířena (ani ve fázi handshake, ani ve fázi dat). Pokud je potvrzení požadováno a příjemce je floodfill, odesílatel by místo toho měl poslat standardní I2NP DatabaseStoreMessage s reply tokenem.
Issues
Mohlo by být také použito ve fázi dat, namísto I2NP DatabaseStoreMessage. Například Bob by ji mohl použít k zahájení fáze dat.
Je povoleno, aby toto obsahovalo RI pro routery jiné než původce, jako obecnou náhradu za DatabaseStoreMessages, např. pro flooding pomocí floodfill routerů?
Funkce odvození klíče (KDF) (pro handshake zprávu 2 a zprávu 3 část 1)
Jediná I2NP zpráva s upraveným hlavičkou. I2NP zprávy nesmí být fragmentovány napříč bloky nebo napříč ChaChaPoly rámci.
Používá prvních 9 bajtů ze standardní NTCP I2NP hlavičky a odebírá posledních 7 bajtů hlavičky následovně: zkrátí expiraci z 8 na 4 bajty, odebere 2-bajtovou délku (použije velikost bloku - 9) a odebere jednobajtový SHA256 kontrolní součet.
+----+----+----+----+----+----+----+----+
| 3 | size |type| msg id |
+----+----+----+----+----+----+----+----+
| short exp | message |
+----+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 3
size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
I2NP message body size is (size - 9).
type :: 1 byte, I2NP msg type, see I2NP spec
msg id :: 4 bytes, big endian, I2NP message ID
short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
Wraps around in 2106
message :: I2NP message body
Notes
- Implementátoři musí zajistit, že při čtení bloku nesprávně formátovaná nebo škodlivá data nezpůsobí, že čtení přesáhne do následujícího bloku.
2) SessionCreated
Noise doporučuje explicitní zprávu o ukončení. Původní NTCP ji nemá. Ukončete spojení. Toto musí být poslední blok bez paddingu v rámci.
+----+----+----+----+----+----+----+----+
| 4 | size | valid data frames |
+----+----+----+----+----+----+----+----+
received | rsn| addl data |
+----+----+----+----+ +
~ . . . ~
+----+----+----+----+----+----+----+----+
blk :: 4
size :: 2 bytes, big endian, value = 9 or more
valid data frames received :: The number of valid AEAD data phase frames received
(current receive nonce value)
0 if error occurs in handshake phase
8 bytes, big endian
rsn :: reason, 1 byte:
0: normal close or unspecified
1: termination received
2: idle timeout
3: router shutdown
4: data phase AEAD failure
5: incompatible options
6: incompatible signature type
7: clock skew
8: padding violation
9: AEAD framing error
10: payload format error
11: message 1 error
12: message 2 error
13: message 3 error
14: intra-frame read timeout
15: RI signature verification fail
16: s parameter missing, invalid, or mismatched in RouterInfo
17: banned
addl data :: optional, 0 or more bytes, for future expansion, debugging,
or reason text.
Format unspecified and may vary based on reason code.
Notes
Ne všechny důvody mohou být skutečně použity, závisí na implementaci. Selhání handshake obecně povede k uzavření s TCP RST namísto toho. Viz poznámky v sekcích handshake zpráv výše. Dodatečné uvedené důvody jsou pro konzistenci, logování, ladění, nebo pokud dojde ke změnám politik.
Padding
Toto slouží pro výplň uvnitř AEAD rámců. Výplň pro zprávy 1 a 2 je mimo AEAD rámce. Veškerá výplň pro zprávu 3 a datovou fázi je uvnitř AEAD rámců.
Padding uvnitř AEAD by měl zhruba odpovídat vyjednaným parametrům. Bob poslal své požadované tx/rx min/max parametry ve zprávě 2. Alice poslala své požadované tx/rx min/max parametry ve zprávě 3. Aktualizované volby mohou být odeslány během datové fáze. Viz informace o bloku voleb výše.
Pokud je přítomen, musí být tento blok posledním blokem v rámci.
+----+----+----+----+----+----+----+----+
|254 | size | padding |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 254
size :: 2 bytes, big endian, size of padding to follow
padding :: random data
Notes
- Strategie paddingu TBD.
- Minimální padding TBD.
- Rámce obsahující pouze padding jsou povoleny.
- Výchozí hodnoty paddingu TBD.
- Viz blok opcí pro vyjednávání parametrů paddingu
- Viz blok opcí pro parametry min/max paddingu
- Noise omezuje zprávy na 64KB. Pokud je potřeba více paddingu, pošlete více rámců.
- Odpověď routeru na porušení vyjednaného paddingu závisí na implementaci.
Other block types
Implementace by měly ignorovat neznámé typy bloků kvůli dopředné kompatibilitě, kromě zprávy 3 část 2, kde neznámé bloky nejsou povoleny.
Future work
- Délka výplně má být rozhodnuta buď na základě jednotlivých zpráv a odhadů distribuce délek, nebo mají být přidány náhodné zpoždění. Tato protiopatření mají být zahrnuta pro odolnost vůči DPI, protože velikosti zpráv by jinak prozradily, že I2P provoz je přenášen transportním protokolem. Přesné schéma výplně je oblastí budoucí práce, Příloha A poskytuje více informací k tomuto tématu.
5) Termination
Připojení mohou být ukončena prostřednictvím normálního nebo abnormálního uzavření TCP socketu, nebo, jak doporučuje Noise, explicitní zprávou o ukončení. Explicitní zpráva o ukončení je definována ve fázi dat výše.
Při jakémkoliv normálním nebo abnormálním ukončení by routery měly vynulovat všechna dočasná data v paměti, včetně dočasných klíčů pro handshake, symetrických kryptografických klíčů a souvisejících informací.
Published Router Info
Šifrování pro handshake zprávu 3 část 1, pomocí zprávy 2 KDF)
Publikovaná RouterAddress (část RouterInfo) bude mít protokolový identifikátor buď “NTCP” nebo “NTCP2”.
RouterAddress musí obsahovat volby “host” a “port”, stejně jako v současném NTCP protokolu.
RouterAddress musí obsahovat tři možnosti pro označení podpory NTCP2:
s=(Base64 klíč) Aktuální Noise statický veřejný klíč (s) pro tuto RouterAddress. Kódovaný pomocí Base 64 se standardní I2P Base 64 abecedou. 32 bajtů v binárním formátu, 44 bajtů jako Base 64 kódovaný, little-endian X25519 veřejný klíč.
i=(Base64 IV) Současný IV pro šifrování hodnoty X ve zprávě 1 pro tuto RouterAddress. Kódováno v Base 64 pomocí standardní I2P Base 64 abecedy. 16 bajtů v binární podobě, 24 bajtů jako Base 64 kódované, big-endian.
v=2 Současná verze (2). Když je publikováno jako “NTCP”, je implicitně podporována také verze 1. Podpora budoucích verzí bude pomocí hodnot oddělených čárkami, např. v=2,3 Implementace by měla ověřit kompatibilitu, včetně více verzí pokud je přítomna čárka. Verze oddělené čárkami musí být v číselném pořadí.
Alice musí ověřit, že všechny tři možnosti jsou přítomny a platné před připojením pomocí protokolu NTCP2.
Když je publikován jako “NTCP” s možnostmi “s”, “i” a “v”, router musí přijímat příchozí spojení na daném hostiteli a portu pro protokoly NTCP i NTCP2 a automaticky detekovat verzi protokolu.
Když je publikováno jako “NTCP2” s možnostmi “s”, “i” a “v”, router přijímá příchozí připojení na tomto hostiteli a portu pouze pro NTCP2 protokol.
Pokud router podporuje jak NTCP1, tak NTCP2 připojení, ale neimplementuje automatickou detekci verze pro příchozí připojení, musí inzerovat jak “NTCP”, tak “NTCP2” adresy a zahrnout NTCP2 možnosti pouze v “NTCP2” adrese. Router by měl nastavit nižší hodnotu nákladů (vyšší prioritu) v “NTCP2” adrese než v “NTCP” adrese, aby bylo NTCP2 preferováno.
Pokud jsou ve stejném RouterInfo publikovány vícenásobné NTCP2 RouterAddresses (buď jako “NTCP” nebo “NTCP2”) (pro další IP adresy nebo porty), všechny adresy specifikující stejný port musí obsahovat identické NTCP2 možnosti a hodnoty. Zejména všechny musí obsahovat stejný statický klíč a iv.
Funkce pro derivaci klíčů (KDF) (pro handshake zprávu 3 část 2)
Pokud Alice nepublikuje svou NTCP2 adresu (jako “NTCP” nebo “NTCP2”) pro příchozí spojení, musí publikovat “NTCP2” router adresu obsahující pouze svůj statický klíč a NTCP2 verzi, aby Bob mohl ověřit klíč po obdržení Alice RouterInfo ve zprávě 3 část 2.
s=(Base64 klíč) Jak je definováno výše pro publikované adresy.
v=2 Jak je definováno výše pro publikované adresy.
Tato adresa routeru nebude obsahovat možnosti “i”, “host” nebo “port”, protože tyto nejsou vyžadovány pro odchozí NTCP2 připojení. Publikované náklady pro tuto adresu nejsou striktně důležité, protože je pouze příchozí; nicméně může být pro ostatní routery užitečné, pokud budou náklady nastaveny výše (nižší priorita) než u ostatních adres. Navrhovaná hodnota je 14.
Alice může také jednoduše přidat možnosti “s” a “v” k existující publikované “NTCP” adrese.
3) SessionConfirmed
Kvůli cachování RouterInfo nesmí routery rotovat statický veřejný klíč nebo IV, dokud je router spuštěný, ať už v publikované adrese nebo ne. Routery musí tento klíč a IV trvale uložit pro opětovné použití po okamžitém restartu, aby příchozí připojení nadále fungovala a časy restartů nebyly odhaleny. Routery musí trvale uložit nebo jinak určit čas posledního vypnutí, aby mohl být při spuštění vypočítán předchozí čas výpadku.
S ohledem na obavy týkající se odhalení časů restartů mohou routery rotovat tento klíč nebo IV při startu, pokud byl router předtím vypnutý po nějakou dobu (minimálně pár hodin).
Pokud má router jakékoliv publikované NTCP2 RouterAddresses (jako NTCP nebo NTCP2), minimální doba nečinnosti před rotací by měla být mnohem delší, například jeden měsíc, pokud se nezměnila místní IP adresa nebo router neprovádí “rekeys”.
Pokud má router jakékolve publikované SSU RouterAddresses, ale ne NTCP2 (jako NTCP nebo NTCP2), měla by být minimální doba výpadku před rotací delší, například jeden den, pokud se nezměnila místní IP adresa nebo router nevykonává “rekeys”. To platí i v případě, že publikovaná SSU adresa má introducers.
Pokud router nemá žádné publikované RouterAddresses (NTCP, NTCP2 nebo SSU), minimální doba nečinnosti před rotací může být kratší než dvě hodiny, dokonce i když se změní IP adresa, pokud router neprovede “rekeys”.
Pokud router “rekeys” na jiný Router Hash, měl by také vygenerovat nový noise klíč a IV.
Implementace si musí být vědomy toho, že změna statického veřejného klíče nebo IV znemožní příchozí NTCP2 připojení od routerů, které mají v mezipaměti starší RouterInfo. Publikování RouterInfo, výběr tunnel peerů (včetně OBGW i IB nejbližšího hopu), výběr zero-hop tunnelů, výběr transportu a další implementační strategie musí toto brát v úvahu.
Rotace IV podléhá stejným pravidlům jako rotace klíčů, s výjimkou toho, že IV nejsou přítomny kromě publikovaných RouterAddresses, takže neexistuje žádné IV pro skryté nebo firewalled routery. Pokud se něco změní (verze, klíč, možnosti?), doporučuje se, aby se IV také změnilo.
Poznámka: Minimální doba výpadku před rekeying může být upravena k zajištění zdraví sítě a k zabránění reseeding routerem, který je nedostupný po mírně delší dobu.
Identity Hiding
Popíratelnost není cílem. Viz přehled výše.
Každému vzoru jsou přiřazeny vlastnosti popisující důvernost poskytovanou statickému veřejnému klíči iniciátora a statickému veřejnému klíči respondenta. Základními předpoklady je, že dočasné soukromé klíče jsou bezpečné a že strany přeruší handshake, pokud obdrží statický veřejný klíč od druhé strany, které nevěří.
Tato sekce se zabývá pouze únikem identity prostřednictvím statických polí veřejných klíčů v handshake. Samozřejmě, identity účastníků Noise mohou být odhaleny i jinými způsoby, včetně polí v datech (payload), analýzy provozu nebo metadat jako jsou IP adresy.
Alice: (8) Šifrováno s forward secrecy k autentizované straně.
Bob: (3) Nepřenáší se, ale pasivní útočník může kontrolovat kandidáty na privátní klíč respondenta a určit, zda je kandidát správný.
Bob publikuje svůj statický veřejný klíč v netDb. Alice může nebo nemusí?
Issues
- Pokud Bob změní svůj statický klíč, mohl by se použít fallback na “XX” pattern?
Noise Protocol Framework
Když je publikováno jako “NTCP”, router musí automaticky detekovat verzi protokolu pro příchozí připojení.
Tato detekce závisí na implementaci, ale zde je obecné doporučení.
Pro detekci verze příchozího NTCP spojení postupuje Bob následovně:
Počkejte na alespoň 64 bajtů (minimální velikost NTCP2 zprávy 1)
Pokud jsou počáteční přijatá data 288 nebo více bajtů, příchozí spojení je verze 1.
Pokud méně než 288 bajtů, pak buď
Počkejte krátkou dobu na další data (dobrá strategie před širokým přijetím NTCP2), pokud bylo přijato alespoň 288 celkem, je to NTCP 1.
Zkuste první fáze dekódování jako verzi 2, pokud selžou, počkejte krátkou dobu na další data (dobrá strategie po širokém přijetí NTCP2)
- Decrypt the first 32 bytes (the X key) of the SessionRequest packet using AES-256 with key RH_B. - Verify a valid point on the curve. If it fails, wait a short time for more data for NTCP 1 - Verify the AEAD frame. If it fails, wait a short time for more data for NTCP 1
Upozorňujeme, že pokud zjistíme aktivní útoky TCP segmentace na NTCP 1, mohou být doporučeny změny nebo další strategie.
Pro usnadnění rychlé detekce verze a handshakingu musí implementace zajistit, aby Alice ukládala do bufferu a poté naráz vyprázdnila celý obsah první zprávy, včetně výplně. To zvyšuje pravděpodobnost, že data budou obsažena v jediném TCP paketu (pokud nebudou segmentována OS nebo middleboxy) a Bob je obdrží najednou. Důvodem je také efektivita a zajištění účinnosti náhodné výplně. Toto platí pro handshaky NTCP i NTCP2.
Dodatky k frameworku
Pokud Alice i Bob podporují NTCP2, Alice by se měla připojit pomocí NTCP2.
Pokud se Alice z jakéhokoli důvodu nepodaří připojit k Bobovi pomocí NTCP2, připojení selže. Alice nesmí opakovat pokus pomocí NTCP 1.
Návrat k XX vzoru pokud Bob změní své klíče? To by vyžadovalo předřazený typ byte?
“Fall forward” na KK vzor, pokud se Alice znovu připojí, za předpokladu, že Bob stále má její statický klíč? Toto neušetří žádné round tripy a používá 4 DH kola oproti 3 pro XK. Pravděpodobně ne.
KK(s, rs):
-> s
<- s
...
-> e, es, ss
<- e, ee, se
Nové kryptografické primitiva pro I2P
Tato sekce se zabývá útokem na typická schémata padding, který umožňuje útočníkům objevit pravděpodobnostní rozdělení délky nezadoplněných zpráv pouze pozorováním délky zadoplněných zpráv. Nechť N je náhodná proměnná popisující počet nezadoplněných bajtů a P podobně pro počet padding bajtů. Celková velikost zprávy je pak N + P.
Předpokládejme, že pro nevyplněnou velikost n je přidáno nejméně P_min(n) >= 0 a nejvýše P_max(n) >= P_min(n) bajtů výplně ve schématu výplně. Zřejmé schéma používá výplň délky P uniformně zvolenou náhodně:
Pr[P = p | N = n] = 1 / (P_max(n) - P_min(n)) if P_min(n) <= p <= P_max(n),
0 otherwise.
Naivní schéma doplňování by jednoduše zajistilo, že velikost doplněné zprávy nepřekročí N_max:
P_max(n) = N_max - n, n <= N_max
P_min(n) = 0.
To však prozrazuje informace o nepaddované délce.
Útočník může snadno odhadnout Pr[x <= N + P <= y], například pomocí histogramu.
- Z toho může také zkusit odhadnout
Pr[n_1 <= N <= n_2], skutečně:
Pr[N + P = m] = Σ_n Pr[N = n] Pr[P = m - n | N = n].
V naivním schématu,
Pr[N + P = m] = Σ_{n <= m} Pr[N = n] / (N_max - n).
Je to docela zřejmé, stejně jako to bylo před provedením výše uvedeného výpočtu, že toto prozrazuje informace o Pr[N = n]: pokud je délka paketů téměř vždy větší než m, pak N + P <= m nebude téměř nikdy pozorováno. To však není největší problém, ačkoli schopnost pozorovat minimální délku zprávy může být sama o sobě považována za problém.
Větší problém je v tom, že je možné určit Pr[N = n] přesně:
Pr[N + P = m] - Pr[N + P = m-1] = Pr[N = m] / (N_max - m),
to je
Pr[N = n] = (N_max - n)(Pr[N + P = n] - Pr[N + P = n - 1])
Pro rozlišení NTCP2 tedy může útočník použít kterýkoli z následujících způsobů:
Odhadněte
Pr[kB <= N <= (k + 1)B - 1]pro kladná celá čísla k. Pro NTCP2 to bude vždy nula.Odhadněte
Pr[N = kB]a porovnejte se standardním I2P profilem.
Tento jednoduchý útok tak částečně ničí účel paddingu, který se pokouší zakrýt distribuci velikostí nevyplněných zpráv. Množství zpráv, které musí útočník pozorovat pro rozlišení protokolu, závisí na požadované přesnosti a na minimálních a maximálních velikostech nevyplněných zpráv, které se vyskytují v praxi. Je důležité poznamenat, že pro útočníka je snadné shromáždit mnoho zpráv, protože může použít veškerý provoz odeslaný z konkrétního portu, který cíl používá, a na něj.
V některých formách (např. odhad Pr[kB <= N <= (k + 1)B - 1]) útok vyžaduje pouze několik bajtů paměti (stačí jeden integer) a dalo by se argumentovat, že takový útok by mohl být zahrnut v mnoha o něco pokročilejších, ale přesto standardních DPI frameworcích.
Tento návrh navrhuje použití jednoho z následujících protiopatření:
Vyvinout alternativní schéma paddingu, které bere v úvahu (odhadované) rozdělení N pomocí neuniformního rozdělení délky paddingu. Dobré padding schéma by pravděpodobně vyžadovalo udržování histogramu počtu bloků na zprávu.
Přidávat náhodné zpoždění mezi (náhodně veliké) fragmenty zpráv.
Druhá možnost je obecně preferována, protože může být současně použita jako protiopatření proti analýze toku. Takové zpoždění však může být mimo rozsah protokolu NTCP2, takže první možnost, která je také jednodušší na implementaci, může být místo toho preferována.
Odhad režie zpracování
Odolnost proti DPI založené na časování (časování/zpoždění mezi zprávami může záviset na implementaci; zpoždění uvnitř zpráv lze zavést v jakémkoli bodě, včetně před odesláním náhodného padding, například). Umělá zpoždění (to, co obfs4 nazývá IAT nebo inter-arrival time) jsou nezávislá na samotném protokolu.