Not
Öneri aşaması kapanmıştır. Resmi spesifikasyon için SPEC bölümüne bakın. Bu öneri hâlâ arka plan bilgisi için referans olarak kullanılabilir.
Genel Bakış
Bu öneri, NTCP protokolünün çeşitli otomatik tanımlama ve saldırı türlerine karşı direncini artırmak için kimlik doğrulamalı bir anahtar anlaşma protokolü tanımlamaktadır.
Teklif şu şekilde organize edilmiştir: güvenlik hedefleri sunulur, ardından temel protokolün tartışması yapılır. Daha sonra, tüm protokol mesajlarının tam bir spesifikasyonu verilir. Son olarak, router adresleri ve versiyon tanımlama tartışılır. Yaygın dolgu şemalarına yönelik genel bir saldırıyı tartışan bir ek de dahil edilmiştir, ayrıca kimliği doğrulanmış şifreleme için bir dizi adayı içeren bir ek de bulunmaktadır.
Diğer I2P taşıma protokolleri gibi, NTCP2 de yalnızca I2NP mesajlarının noktadan noktaya (router’dan router’a) taşınması için tanımlanmıştır. Genel amaçlı bir veri kanalı değildir.
Motivasyon
NTCP verisi ilk mesajdan sonra şifrelenir (ve ilk mesaj rastgele veri gibi görünür), böylece “payload analizi” yoluyla protokol tanımlaması engellenir. Ancak “akış analizi” yoluyla protokol tanımlamaya karşı hala savunmasızdır. Bunun nedeni ilk 4 mesajın (yani handshake) sabit uzunlukta olmasıdır (288, 304, 448 ve 48 byte).
Her mesaja rastgele miktarlarda rastgele veri ekleyerek, bunu çok daha zor hale getirebiliriz.
Yazarlar, standart güvenlik uygulamalarının TLS gibi mevcut bir protokol kullanılmasını önerdiğini kabul etmektedirler, ancak bu Prop104 olup kendi sorunları bulunmaktadır. Uygun olan yerlerde, eksik özellikleri veya tartışma konularını belirtmek için “gelecekteki çalışmalar” paragrafları eklenmiştir.
Tasarım Hedefleri
Tek bir portta NTCP 1 ve 2’yi destekle, otomatik algıla ve NetDB‘de tek bir “transport” (yani RouterAddress) olarak yayınla.
NetDB’de ayrı bir alanda yalnızca sürüm 1, yalnızca sürüm 2 veya 1+2 için yayınlama desteği sağlayın ve varsayılan olarak yalnızca sürüm 1’i kullanın (sürüm desteğini belirli bir router sürümüne bağlamayın)
Tüm uygulamaların (Java/i2pd/Kovri/go) kendi programlarına göre sürüm 2 desteğini ekleyebilmesini (veya eklememesini) sağlamak
Handshake ve veri mesajları dahil tüm NTCP mesajlarına rastgele dolgu ekleme (yani uzunluk gizleme böylece tüm mesajlar 16 baytın katı olmaz) Her iki tarafın minimum ve maksimum dolgu ve/veya dolgu dağılımı talep edebilmesi için seçenekler mekanizması sağlama. Dolgu dağılımının detayları implementasyona bağlıdır ve protokolün kendisinde belirtilip belirtilmeyebilir.
Şifrelenmemiş mesajların içeriğini (1 ve 2) gizle, DPI kutuları ve AV imzalarının bunları kolayca sınıflandıramaması için yeterli düzeyde. Ayrıca tek bir peer’a veya peer grubuna giden mesajların benzer bit desenlerine sahip olmadığından emin ol.
Java formatı nedeniyle DH’de bit kaybını düzelt Ticket1112, muhtemelen (büyük ihtimalle?) X25519’a geçiş yaparak.
DH sonucunu olduğu gibi kullanmak yerine gerçek bir anahtar türetme fonksiyonuna (KDF) geçilmeli mi?
“Probing resistance” (Tor’un adlandırdığı gibi) ekle; bu replay resistance’ı da içerir.
2 yönlü kimlik doğrulamalı anahtar değişimini (2W-AKE) sürdürün. 1W-AKE uygulamamız için yeterli değildir.
Kimlik doğrulamanın bir parçası olarak değişken tipli, değişken uzunluklu imzaları (yayınlanmış RouterIdentity imzalama anahtarından) kullanmaya devam edin. Kimlik doğrulamanın başka bir parçası olarak RouterInfo içinde yayınlanmış statik genel anahtara güvenin.
Gelecekteki genişletilebilirlik için el sıkışmada options/version ekle.
Mümkünse kötü niyetli MitM TCP segmentasyonuna karşı direnç ekleyin.
Bağlantı kurulumu için gereken CPU’ya önemli ölçüde ekleme yapmayın; mümkünse, önemli ölçüde azaltın.
Mesaj kimlik doğrulama (MAC) ekle, muhtemelen HMAC-SHA256 ve Poly1305, ve Adler checksum’ını kaldır.
I2NP başlığını kısaltın ve basitleştirin: SSU’da olduğu gibi süre dolumunu 4 bayta kısaltın. Tek baytlık kırpılmış SHA256 sağlama toplamını kaldırın.
Mümkünse, 4 mesajlı, iki gidiş-dönüş el sıkışmasını SSU‘daki gibi 3 mesajlı, tek gidiş-dönüş el sıkışmasına indirin. Bu, Bob’un mesaj 4’teki imzasının mesaj 2’ye taşınmasını gerektirecektir. On yıllık e-posta/durum/toplantı arşivlerinde 4 mesajın nedenini araştırın.
Dolgu öncesi protokol ek yükünü minimize edin. Dolgu eklenecek olsa da, ve muhtemelen çok miktarda, dolgu öncesi ek yük yine de ek yüktür. Düşük bant genişlikli düğümler NTCP2 kullanabilmelidir.
Tekrar saldırısı ve sapma tespiti için zaman damgalarını koruyun.
Zaman damgalarında 2038 yılı sorunlarından kaçının, en az 2106 yılına kadar çalışmalıdır.
Maksimum mesaj boyutunu 16K’dan 32K veya 64K’ya artır.
Herhangi bir yeni kriptografik ilkel, Java (1.7), C++ ve Go router uygulamalarında kullanım için kütüphanelerde kolayca erişilebilir olmalıdır.
Tasarımda Java, C++ ve Go router geliştiricilerinin temsilcilerini dahil edin.
Değişiklikleri minimize edin (yine de çok fazla değişiklik olacaktır).
Ortak bir kod setinde her iki versiyonu da destekle (bu mümkün olmayabilir ve her durumda implementasyona bağlıdır).
Non-Goals
Kurşun geçirmez DPI direnci… bu pluggable transport’lar olacaktır, Prop109.
TLS tabanlı (veya HTTPS benzeri) bir aktarım… bu Prop104 olacaktır.
Simetrik akış kriptografisini değiştirmek sorun değil.
Zamanlama tabanlı DPI direnci (mesajlar arası zamanlama/gecikmeler uygulama bağımlı olabilir; mesaj içi gecikmeler, örneğin rastgele dolgu gönderilmeden önce dahil olmak üzere herhangi bir noktada eklenebilir). Yapay gecikmeler (obfs4’ün IAT veya varış arası süre dediği) protokolün kendisinden bağımsızdır.
Bir oturuma katılımın inkâr edilebilirliği (içinde imzalar bulunur).
Kısmen yeniden değerlendirilebilecek veya tartışılabilecek hedef olmayanlar:
Deep Packet Inspection (DPI) karşı koruma derecesi
Post-Quantum (PQ) güvenliği
İnkar edilebilirlik
Related Goals
- Bir NTCP 1/2 test kurulumu uygulayın
Security Goals
Üç tarafı ele alıyoruz:
- Yeni bir oturum kurmak isteyen Alice.
- Alice’in oturum kurmak istediği Bob.
- Alice ve Bob arasında “ortadaki adam” olan Mallory.
En fazla iki katılımcı aktif saldırılarda bulunabilir.
Alice ve Bob’un her ikisi de RouterIdentity’lerinde bulunan statik bir anahtar çiftine sahiptir.
Önerilen protokol, Alice ve Bob’un aşağıdaki gereksinimler altında paylaşılan bir gizli anahtar (K) üzerinde anlaşmalarına izin vermeye çalışır:
Özel anahtar güvenliği: ne Bob ne de Mallory, Alice’in statik özel anahtarı hakkında hiçbir şey öğrenmez. Simetrik olarak, Alice de Bob’un statik özel anahtarı hakkında hiçbir şey öğrenmez.
Oturum anahtarı K yalnızca Alice ve Bob tarafından bilinir.
Mükemmel ileri gizlilik: üzerinde anlaşılan oturum anahtarı gelecekte gizli kalır, Alice ve/veya Bob’un statik özel anahtarları anahtar üzerinde anlaşma sağlandıktan sonra açığa çıkarılsa bile.
İki yönlü kimlik doğrulama: Alice, Bob ile bir oturum kurduğundan emindir ve tam tersi de geçerlidir.
Çevrimiçi DPI’ya karşı koruma: Alice ve Bob’un protokolde yer aldığının yalnızca basit derin paket inceleme (DPI) teknikleri kullanılarak tespit edilmesinin önemsiz olmadığından emin olun. Aşağıya bakın.
Sınırlı inkar edilebilirlik: ne Alice ne de Bob protokole katılımını inkar edemez, ancak taraflardan biri paylaşılan anahtarı sızdırırsa diğer taraf iletilen verinin içeriğinin gerçekliğini inkar edebilir.
Mevcut öneri, Station-To-Station (STS) protokolü temelinde beş gereksinimin tamamını sağlamaya çalışmaktadır. Bu protokolün aynı zamanda SSU protokolünün de temelini oluşturduğunu unutmayın.
Additional DPI Discussion
İki DPI bileşeni varsayıyoruz:
1) Online DPI
Tüm akışları gerçek zamanlı olarak inceleyen çevrimiçi DPI. Bağlantılar engellenebilir veya başka şekilde müdahale edilebilir. Bağlantı verileri veya metadata’ları tanımlanabilir ve çevrimdışı analiz için saklanabilir. Çevrimiçi DPI, I2P ağ veritabanına erişime sahip değildir. Çevrimiçi DPI yalnızca uzunluk hesaplama, alan inceleme ve XOR gibi basit hesaplamalar dahil olmak üzere sınırlı gerçek zamanlı hesaplama kapasitesine sahiptir. Çevrimiçi DPI, AES, AEAD ve hashing gibi hızlı gerçek zamanlı kriptografik fonksiyonlara sahiptir, ancak bunları çoğu veya tüm akışlara uygulamak çok maliyetli olacaktır. Bu kriptografik işlemlerin herhangi bir uygulaması yalnızca çevrimdışı analiz tarafından önceden tanımlanmış IP/Port kombinasyonlarındaki akışlara uygulanacaktır. Çevrimiçi DPI, DH veya elligator2 gibi yüksek yükü olan kriptografik fonksiyon kapasitesine sahip değildir. Çevrimiçi DPI, I2P’yi tespit etmek için özel olarak tasarlanmamıştır, ancak bu amaçla sınırlı sınıflandırma kurallarına sahip olabilir.
Çevrimiçi bir DPI tarafından protokol tanımlamasını önlemek bir hedeftir.
Çevrimiçi veya “doğrudan” DPI kavramı burada aşağıdaki düşman yeteneklerini içerecek şekilde ele alınmıştır:
Hedefin gönderdiği veya aldığı tüm verileri inceleme yeteneği.
Gözlemlenen veriler üzerinde blok şifreler veya hash fonksiyonları uygulama gibi işlemler gerçekleştirme yeteneği.
Daha önce gönderilen mesajları saklama ve bunlarla karşılaştırma yeteneği.
Paketleri değiştirme, geciktirme veya parçalara ayırma yeteneği.
Ancak, çevrimiçi DPI’nin aşağıdaki kısıtlamalara sahip olduğu varsayılmaktadır:
IP adreslerini router hash’lerine eşleyememek. Bu, network database’e gerçek zamanlı erişimle önemsiz olsa da, özellikle I2P’yi hedeflemek için tasarlanmış bir DPI sistemi gerektirecektir.
Protokolü tespit etmek için zamanlama bilgisinin kullanılamaması.
Genel olarak konuşmak gerekirse, çevrimiçi DPI araç kutusu özellikle I2P tespiti için tasarlanmış herhangi bir yerleşik araç içermez. Bu, örneğin mesajlarında rastgele olmayan dolgu içerecek olan “honeypot’lar” oluşturmayı da kapsar. Bunun, diğer gereksinimleri karşıladıkları sürece makine öğrenmesi sistemlerini veya yüksek düzeyde yapılandırılabilir DPI araçlarını hariç tutmadığını unutmayın.
Payload analizi ile mücadele etmek için, tüm mesajların rastgele veriden ayırt edilemez olması sağlanır. Bu aynı zamanda uzunluklarının da rastgele olmasını gerektirir ki bu, sadece rastgele padding eklemekten daha karmaşıktır. Nitekim, Ek A’da yazarlar naif (yani düzgün) bir padding şemasının sorunu çözmediğini savunmaktadırlar. Bu nedenle Ek A, önerilen saldırıya karşı makul koruma sağlayabilecek rastgele gecikmeler dahil etmeyi veya alternatif bir padding şeması geliştirmeyi önermektedir.
Yukarıdaki altıncı maddeye karşı korunmak için, implementasyonlar protokolde rastgele gecikmeler içermelidir. Bu tür teknikler bu öneri kapsamında ele alınmamaktadır, ancak bunlar aynı zamanda padding uzunluğu sorunlarını da çözebilir. Özetle, öneri payload analizine karşı (Ek A’daki hususlar dikkate alındığında) iyi koruma sağlar, ancak akış analizine karşı yalnızca sınırlı koruma sunar.
2) Offline DPI
Çevrimdışı DPI, sonraki analiz için çevrimiçi DPI tarafından depolanan verileri incelemektedir. Çevrimdışı DPI, özellikle I2P’yi tespit etmek için tasarlanmış olabilir. Çevrimdışı DPI’nin I2P network database’ine gerçek zamanlı erişimi bulunmamaktadır. Çevrimdışı DPI’nin bu ve diğer I2P spesifikasyonlarına erişimi bulunmaktadır. Çevrimdışı DPI, bu spesifikasyonda tanımlanan tüm kriptografik fonksiyonlar dahil olmak üzere sınırsız hesaplama kapasitesine sahiptir.
Çevrimdışı DPI mevcut bağlantıları engelleme yeteneğine sahip değildir. Çevrimdışı DPI, taraflara host/port’a yakın gerçek zamanlı (kurulumdan dakikalar içinde) gönderme yeteneğine sahiptir, örneğin TCP RST. Çevrimdışı DPI, “araştırma” veya diğer nedenler için önceki mesajların (değiştirilmiş olsun ya da olmasın) yakın gerçek zamanlı (kurulumdan dakikalar içinde) yeniden oynatma yeteneğine sahiptir.
Çevrimdışı bir DPI tarafından protokol tanımlamasını önlemek bir hedef değildir. I2P router’ları tarafından uygulanan ilk iki mesajdaki gizlenmiş verilerin tüm çözümlemesi, çevrimdışı DPI tarafından da uygulanabilir.
Önceki mesajların tekrarını kullanarak yapılan bağlantı girişimlerini reddetmek bir hedeftir.
Future work
Paketlerin bir saldırgan tarafından düşürüldüğü veya yeniden sıralandığı durumlarda protokolün davranışını göz önünde bulundurun. Bu alandaki son ilginç çalışma IACR-1150 adresinde bulunabilir.
Konuyla ilgili mevcut literatürü dikkate alarak DPI sistemlerinin daha doğru bir sınıflandırmasını sağlamak.
Önerilen protokolün formal güvenliğini tartışın, ideal olarak DPI saldırgan modelini dikkate alarak.
Noise Protocol Framework
Bu öneri, Noise Protocol Framework NOISE (Revizyon 33, 2017-10-04) tabanlı gereksinimleri sağlar. Noise, SSU protokolünün temelini oluşturan Station-To-Station protokolüne benzer özelliklere sahiptir. Noise terminolojisinde Alice başlatıcı, Bob ise yanıtlayıcıdır.
NTCP2, Noise protokolü Noise_XK_25519_ChaChaPoly_SHA256 tabanlıdır. (İlk anahtar türetme fonksiyonu için gerçek tanımlayıcı, I2P uzantılarını belirtmek amacıyla “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256”‘dır - aşağıdaki KDF 1 bölümüne bakın) Bu Noise protokolü aşağıdaki temel öğeleri kullanır:
Handshake Pattern: XK Alice anahtarını Bob’a iletir (X) Alice, Bob’un statik anahtarını zaten biliyor (K)
DH Function: X25519 RFC-7748‘de belirtildiği gibi 32 bayt anahtar uzunluğuna sahip X25519 DH.
Cipher Function: ChaChaPoly RFC-7539 bölüm 2.8’de belirtildiği gibi AEAD_CHACHA20_POLY1305. 12 bayt nonce, ilk 4 bayt sıfıra ayarlanmış.
Hash Function: SHA256 I2P’de halihazırda yaygın olarak kullanılan standart 32-byte hash.
Güvenlik Hedefleri
Bu öneri, Noise_XK_25519_ChaChaPoly_SHA256’ya aşağıdaki geliştirmeleri tanımlar. Bunlar genellikle NOISE bölüm 13’teki yönergeleri takip eder.
Cleartext ephemeral anahtarlar bilinen bir anahtar ve IV kullanarak AES şifreleme ile gizlenir. Bu elligator2’den daha hızlıdır.
Mesaj 1 ve 2’ye rastgele cleartext padding eklenir. Cleartext padding, handshake hash (MixHash) hesaplamasına dahil edilir. Mesaj 2 ve mesaj 3 kısım 1 için aşağıdaki KDF bölümlerine bakınız. Mesaj 3 ve veri fazı mesajlarına rastgele AEAD padding eklenir.
İki baytlık bir çerçeve uzunluğu alanı eklenir, bu TCP üzerinden Noise için gereklidir ve obfs4’teki gibidir. Bu yalnızca veri aşaması mesajlarında kullanılır. Mesaj 1 ve 2 AEAD çerçeveleri sabit uzunluktadır. Mesaj 3 bölüm 1 AEAD çerçevesi sabit uzunluktadır. Mesaj 3 bölüm 2 AEAD çerçeve uzunluğu mesaj 1’de belirtilir.
İki baytlık frame uzunluğu alanı, obfs4’te olduğu gibi SipHash-2-4 ile gizlenir.
Payload formatı 1, 2, 3 numaralı mesajlar ve veri aşaması için tanımlanmıştır. Tabii ki bu Noise’da tanımlanmamıştır.
New Cryptographic Primitives for I2P
Mevcut I2P router uygulamaları, güncel I2P protokolleri için gerekli olmayan aşağıdaki standart kriptografik temel öğeler için uygulamalar gerektirecektir:
X25519 anahtar üretimi ve DH
AEAD_ChaCha20_Poly1305 (aşağıda ChaChaPoly olarak kısaltılmıştır)
SipHash-2-4
Processing overhead estimate
3 mesaj için mesaj boyutları:
- 64 bayt + dolgu (NTCP 288 bayttı) 2) 64 bayt + dolgu (NTCP 304 bayttı) 3) yaklaşık 64 bayt + Alice router bilgisi + dolgu Ortalama router bilgisi yaklaşık 750 bayt Dolgu öncesi toplam ortalama 814 bayt (NTCP 448 bayttı) 4) NTCP2’de gerekli değil (NTCP 48 bayttı)
Dolgu öncesi toplam: NTCP2: 942 bayt NTCP: 1088 bayt Alice’in Bob’a RouterInfo’sunun DatabaseStore Mesajını göndermek amacıyla bağlanması durumunda, bu mesaj gerekli olmadığından yaklaşık 800 bayt tasarruf sağlanacağını unutmayın.
Aşağıdaki kriptografik işlemler, her bir tarafın el sıkışmayı tamamlaması ve veri aşamasını başlatması için gereklidir:
- AES: 2
- SHA256: 7 (Alice), 6 (Bob) (tüm bağlantılar için önceden hesaplanan 1 Alice, 2 Bob dahil değil) (HMAC-SHA256 dahil değil)
- HMAC-SHA256: 19
- ChaChaPoly: 4
- X25519 anahtar üretimi: 1
- X25519 DH: 3
- İmza doğrulama: 1 (Bob) (Alice daha önce RI’sını oluştururken imzalamıştı) Muhtemelen Ed25519 (RI imza türüne bağlı)
Her veri faz mesajı için her bir tarafın gerçekleştirmesi gereken kriptografik işlemler şunlardır:
- SipHash: 1
- ChaChaPoly: 1
Messages
Tüm NTCP2 mesajları uzunluk olarak 65537 bayt veya daha kısadır. Mesaj formatı Noise mesajlarına dayalıdır, çerçeveleme ve ayırt edilemezlik için değişiklikler içerir. Standart Noise kütüphaneleri kullanan uygulamaların, alınan mesajları Noise mesaj formatına/formatından ön işleme tabi tutması gerekebilir. Tüm şifrelenmiş alanlar AEAD şifreli metinleridir.
Kurulum sırası aşağıdaki gibidir:
Alice Bob
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->
Noise terminolojisini kullanarak, kurulum ve veri dizisi şu şekildedir: (Payload Güvenlik Özellikleri)
XK(s, rs): Authentication Confidentiality
<- s
...
-> e, es 0 2
<- e, ee 2 1
-> s, se 2 5
<- 2 5
Bir oturum kurulduktan sonra, Alice ve Bob Data mesajları alışverişi yapabilir.
Tüm mesaj türleri (SessionRequest, SessionCreated, SessionConfirmed, Data ve TimeSync) bu bölümde belirtilmiştir.
Bazı gösterimler:
- RH_A = Alice için Router Hash (32 bayt)
- RH_B = Bob için Router Hash (32 bayt)
Authenticated Encryption
Üç ayrı doğrulanmış şifreleme örneği (CipherStates) bulunur. Biri handshake aşamasında, ikisi (gönderme ve alma) veri aşamasında kullanılır. Her birinin KDF’den gelen kendi anahtarı vardır.
Şifrelenmiş/doğrulanmış veriler şu şekilde temsil edilecektir
+----+----+----+----+----+----+----+----+
| |
+ +
| Encrypted and authenticated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Hedefler Dışında Kalanlar
Şifrelenmiş ve doğrulanmış veri formatı.
Şifreleme/şifre çözme fonksiyonlarına girdiler:
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
Şifreleme fonksiyonunun çıktısı, şifre çözme fonksiyonunun girdisi:
+----+----+----+----+----+----+----+----+
|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
ChaCha20 için, burada açıklanan RFC-7539‘a karşılık gelir ve bu aynı zamanda TLS RFC-7905’te de benzer şekilde kullanılır.
Notes
ChaCha20 bir akış şifresi olduğundan, düz metinlerin doldurulması gerekmez. Ek anahtar akışı baytları atılır.
Şifre için anahtar (256 bit) SHA256 KDF aracılığıyla kararlaştırılır. Her mesaj için KDF detayları aşağıdaki ayrı bölümlerde yer almaktadır.
Mesaj 1, 2 ve mesaj 3’ün ilk bölümü için ChaChaPoly çerçeveleri bilinen boyuttadır. Mesaj 3’ün ikinci bölümünden başlayarak, çerçeveler değişken boyuttadır. Mesaj 3 bölüm 1 boyutu mesaj 1’de belirtilir. Veri aşamasından başlayarak, çerçevelerin başına obfs4’teki gibi SipHash ile gizlenmiş iki baytlık uzunluk eklenir.
Dolgu, mesaj 1 ve 2 için kimlik doğrulamalı veri çerçevesinin dışındadır. Dolgu, bir sonraki mesaj için KDF’de kullanılır, bu nedenle kurcalama tespit edilecektir. Mesaj 3’ten başlayarak, dolgu kimlik doğrulamalı veri çerçevesinin içindedir.
İlgili Hedefler
Mesaj 1, 2 ve mesaj 3’ün 1. ve 2. bölümlerinde, AEAD mesaj boyutu önceden bilinir. AEAD kimlik doğrulama hatasında, alıcı daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu anormal bir kapatma (TCP RST) olmalıdır.
Probing direnci için, mesaj 1’de, bir AEAD hatasından sonra, Bob rastgele bir zaman aşımı (aralık TBD) ayarlamalı ve soketi kapatmadan önce rastgele sayıda bayt (aralık TBD) okumalıdır. Bob, tekrarlanan hatalar olan IP’lerin kara listesini tutmalıdır.
Veri aşamasında, AEAD mesaj boyutu SipHash ile “şifrelenir” (gizlenir). Bir çözümleme oracle’ı oluşturmamaya dikkat edilmelidir. Bir veri aşaması AEAD doğrulama başarısızlığında, alıcı rastgele bir zaman aşımı (aralık TBD) belirlemeli ve ardından rastgele sayıda bayt (aralık TBD) okumalıdır. Okuma işleminden sonra veya okuma zaman aşımında, alıcı “AEAD başarısızlığı” neden kodu içeren bir sonlandırma bloğu ile bir payload göndermeli ve bağlantıyı kapatmalıdır.
Veri aşamasında geçersiz uzunluk alanı değeri için aynı hata eylemini gerçekleştirin.
Key Derivation Function (KDF) (for handshake message 1)
KDF, DH sonucundan bir handshake fazı şifre anahtarı k üretir ve RFC-2104’te tanımlandığı gibi HMAC-SHA256(key, data) kullanır. Bunlar, Noise spesifikasyonunda tam olarak tanımlandığı şekliyle InitializeSymmetric(), MixHash(), ve MixKey() fonksiyonlarıdır.
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.
Ek DPI Tartışması
Alice, Bob’a gönderir.
Noise içeriği: Alice’in geçici anahtarı X Noise yükü: 16 bayt seçenek bloğu Noise olmayan yük: Rastgele dolgu
(Payload Güvenlik Özellikleri)
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.
X değeri, gerekli DPI karşı önlemleri olan payload ayırt edilemezliği ve benzersizliği sağlamak için şifrelenir. Bunu başarmak için elligator2 gibi daha karmaşık ve yavaş alternatiflere değil AES şifrelemesini kullanırız. Bob’un router genel anahtarına asimetrik şifreleme çok daha yavaş olacaktır. AES şifreleme, anahtar olarak Bob’un router hash’ini ve network database’de yayınlanan Bob’un IV’sini kullanır.
AES şifrelemesi yalnızca DPI direnci içindir. Bob’un router hash’ini ve ağ veritabanında yayınlanan IV’yi bilen herhangi bir taraf, bu mesajdaki X değerini şifresini çözebilir.
Dolgu Alice tarafından şifrelenmez. Zamanlama saldırılarını engellemek için Bob’un dolguyu şifresini çözmesi gerekebilir.
Ham içerikler:
+----+----+----+----+----+----+----+----+
| |
+ 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.
Şifrelenmemiş veri (Poly1305 doğrulama etiketi gösterilmemiş):
+----+----+----+----+----+----+----+----+
| |
+ +
| 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.
Seçenekler bloğu: Not: Tüm alanlar big-endian formatındadır.
+----+----+----+----+----+----+----+----+
| 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
Yayınlanan adres “NTCP” olduğunda, Bob aynı port üzerinde hem NTCP hem de NTCP2’yi destekler. Uyumluluk için, “NTCP” olarak yayınlanan bir adrese bağlantı başlatırken, Alice bu mesajın maksimum boyutunu, dolgu dahil olmak üzere, 287 bayt veya daha az ile sınırlamalıdır. Bu, Bob’un otomatik protokol tanımlamasını kolaylaştırır. “NTCP2” olarak yayınlandığında, boyut kısıtlaması yoktur. Aşağıdaki Yayınlanan Adresler ve Sürüm Algılama bölümlerine bakın.
İlk AES blokundaki benzersiz X değeri, şifreli metnin her oturum için farklı olmasını sağlar.
Bob, zaman damgası değeri mevcut zamandan çok farklı olan bağlantıları reddetmelidir. Maksimum delta zamanını “D” olarak adlandırın. Bob, tekrar saldırılarını önlemek için daha önce kullanılmış handshake değerlerinin yerel bir önbelleğini tutmalı ve kopyaları reddetmelidir. Önbellekteki değerler en az 2*D yaşam süresine sahip olmalıdır. Önbellek değerleri uygulama bağımlıdır, ancak 32-byte X değeri (veya şifrelenmiş eşdeğeri) kullanılabilir.
Diffie-Hellman geçici anahtarları kriptografik saldırıları önlemek için asla yeniden kullanılmamalıdır ve yeniden kullanım tekrar saldırısı olarak reddedilecektir.
“KE” ve “auth” seçenekleri uyumlu olmalıdır, yani paylaşılan gizli anahtar K uygun boyutta olmalıdır. Daha fazla “auth” seçeneği eklenirse, bu “KE” bayrağının anlamını farklı bir KDF kullanmak veya farklı bir kesme boyutu kullanmak için dolaylı olarak değiştirebilir.
Bob, Alice’in geçici anahtarının burada eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
Padding makul bir miktarla sınırlandırılmalıdır. Bob aşırı padding içeren bağlantıları reddedebilir. Bob, padding seçeneklerini mesaj 2’de belirtecektir. Min/maks yönergeleri henüz belirlenmedi. 0 ile 31 byte arasında minimum rastgele boyut? (Dağılım belirlenecek, Ek A’ya bakın.)
AEAD, DH, zaman damgası, görünür tekrar saldırısı veya anahtar doğrulama hatası dahil herhangi bir hatada, Bob daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu anormal bir kapatma (TCP RST) olmalıdır. Araştırma direnci için, AEAD hatasından sonra, Bob rastgele bir zaman aşımı (aralık TBD) ayarlamalı ve ardından rastgele sayıda bayt (aralık TBD) okumalı, socket’i kapatmadan önce.
DoS Azaltımı: DH nispeten pahalı bir işlemdir. Önceki NTCP protokolünde olduğu gibi, router’lar CPU veya bağlantı tükenmesini önlemek için gerekli tüm önlemleri almalıdır. Maksimum aktif bağlantılar ve devam eden maksimum bağlantı kurulumları için sınırlar koyun. Okuma zaman aşımlarını uygulayın (hem okuma başına hem de “slowloris” için toplam). Aynı kaynaktan tekrarlanan veya eşzamanlı bağlantıları sınırlayın. Tekrar tekrar başarısız olan kaynaklar için kara liste tutun. AEAD başarısızlığına yanıt vermeyin.
Hızlı sürüm algılama ve el sıkışmayı kolaylaştırmak için, uygulamalar Alice’in ilk mesajın tüm içeriğini (dolgu dahil) tamponlamasını ve ardından bir seferde boşaltmasını sağlamalıdır. Bu, verilerin tek bir TCP paketinde (işletim sistemi veya ara kutular tarafından bölünmedikçe) yer alma olasılığını artırır ve Bob tarafından aynı anda alınmasını sağlar. Ek olarak, uygulamalar Bob’un ikinci mesajın tüm içeriğini (dolgu dahil) tamponlamasını ve ardından bir seferde boşaltmasını sağlamalıdır. Ayrıca Bob’un üçüncü mesajın tüm içeriğini tamponlaması ve bir seferde boşaltması gerekir. Bu da verimlilik için ve rastgele dolgunun etkinliğini sağlamak içindir.
“ver” alanı: Genel Noise protokolü, uzantılar ve yük belirtimlerini içeren NTCP protokolü, NTCP2’yi belirtir. Bu alan gelecekteki değişiklikler için desteği belirtmek amacıyla kullanılabilir.
Mesaj 3 bölüm 2 uzunluğu: Bu, SessionConfirmed mesajında gönderilecek olan Alice’in Router Info’sunu ve isteğe bağlı padding’i içeren ikinci AEAD çerçevesinin boyutudur (16-byte MAC dahil). Router’lar periyodik olarak Router Info’larını yeniden oluşturup yeniden yayınladıkları için, mevcut Router Info’nun boyutu mesaj 3 gönderilmeden önce değişebilir. Uygulamalar iki stratejiden birini seçmelidir: a) mesaj 3’te gönderilecek mevcut Router Info’yu kaydetmek, böylece boyut bilinir, ve isteğe bağlı olarak padding için yer eklemek; b) Router Info boyutundaki olası artışa izin verecek kadar belirtilen boyutu artırmak ve mesaj 3 gerçekten gönderildiğinde her zaman padding eklemek. Her iki durumda da, mesaj 1’e dahil edilen “m3p2len” uzunluğu, mesaj 3’te gönderildiğinde o çerçevenin tam boyutu olmalıdır.
Bob, mesaj 1’i doğruladıktan ve padding’i okuduktan sonra herhangi bir gelen veri kalırsa bağlantıyı sonlandırmalıdır. Alice’ten fazladan veri olmamalıdır, çünkü Bob henüz mesaj 2 ile yanıt vermemiştir.
Network ID alanı, çapraz ağ bağlantılarını hızlıca tanımlamak için kullanılır. Bu alan sıfırdan farklıysa ve Bob’un network ID’si ile eşleşmiyorsa, Bob bağlantıyı kesip gelecek bağlantıları engellemeli. 0.9.42 sürümünden itibaren. Daha fazla bilgi için öneri 147’ye bakın.
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, Alice’e gönderir.
Noise içeriği: Bob’un ephemeral anahtarı Y Noise yükü: 16 bayt seçenek bloğu Noise olmayan yük: Rastgele dolgu
(Payload Güvenlik Özellikleri)
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.
Y değeri, DPI karşı önlemleri için gerekli olan yük ayırt edilemezliği ve benzersizliği sağlamak amacıyla şifrelenir. Bunu başarmak için elligator2 gibi daha karmaşık ve yavaş alternatiflere kıyasla AES şifreleme kullanırız. Alice’ın router genel anahtarına asimetrik şifreleme çok yavaş olurdu. AES şifreleme Bob’un router hash’ini anahtar olarak ve mesaj 1’den gelen AES durumunu (network database’de yayınlanan Bob’un IV’si ile başlatılmış olan) kullanır.
AES şifreleme yalnızca DPI direnci içindir. Bob’un router hash’ini ve network database’de yayınlanan IV’sini bilen ve mesaj 1’in ilk 32 baytını yakalayan herhangi bir taraf, bu mesajdaki Y değerini deşifre edebilir.
Ham içerikler:
+----+----+----+----+----+----+----+----+
| |
+ 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
Şifrelenmemiş veri (Poly1305 auth tag gösterilmemiş):
+----+----+----+----+----+----+----+----+
| |
+ +
| 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, Bob’un geçici anahtarının burada eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
Padding makul bir miktarla sınırlandırılmalıdır. Alice aşırı padding içeren bağlantıları reddedebilir. Alice padding seçeneklerini mesaj 3’te belirtecektir. Min/max yönergeleri henüz belirlenmemiştir. 0 ile 31 byte arası rastgele boyut minimum? (Dağılım belirlenecek, bkz. Ek A.)
Herhangi bir hata durumunda, AEAD, DH, zaman damgası, görünür tekrar oynatma veya anahtar doğrulama hatası da dahil olmak üzere, Alice daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu anormal bir kapatma olmalıdır (TCP RST).
Hızlı el sıkışmayı kolaylaştırmak için, uygulamalar Bob’un dolgu dahil olmak üzere ilk mesajın tüm içeriğini tamponlamasını ve ardından bir kerede boşaltmasını sağlamalıdır. Bu, verilerin (işletim sistemi veya middlebox’lar tarafından segmentlenmediği sürece) tek bir TCP paketinde bulunma ve Alice tarafından aynı anda alınma olasılığını artırır. Bu aynı zamanda verimlilik ve rastgele dolgunun etkinliğini sağlamak içindir.
Alice, mesaj 2’yi doğruladıktan ve padding’i okuduktan sonra gelen veriler kalırsa bağlantıyı başarısız kılmalıdır. Bob’dan ekstra veri olmamalıdır, çünkü Alice henüz mesaj 3 ile yanıt vermemiştir.
Seçenekler bloğu: Not: Tüm alanlar big-endian’dır.
+----+----+----+----+----+----+----+----+
| 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, zaman damgası değeri mevcut zamandan çok uzak olan bağlantıları reddetmelidir. Maksimum delta zamanını “D” olarak adlandırın. Alice, tekrar saldırılarını önlemek için daha önce kullanılmış handshake değerlerinin yerel bir önbelleğini tutmalı ve yinelenenleri reddetmelidir. Önbellekteki değerler en az 2*D yaşam süresine sahip olmalıdır. Önbellek değerleri uygulama bağımlıdır, ancak 32-byte Y değeri (veya şifreli eşdeğeri) kullanılabilir.
Issues
- Min/max dolgu seçenekleri buraya dahil edilsin mi?
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, Bob’a gönderir.
Noise içeriği: Alice’in statik anahtarı Noise yükü: Alice’in RouterInfo’su ve rastgele dolgu Non-noise yükü: yok
(Payload Güvenlik Özellikleri)
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.
Bu iki ChaChaPoly çerçevesi içerir. İlki Alice’in şifrelenmiş statik açık anahtarıdır. İkincisi Noise payload’ıdır: Alice’in şifrelenmiş RouterInfo’su, isteğe bağlı seçenekler ve isteğe bağlı padding. Bunlar farklı anahtarlar kullanır çünkü MixKey() fonksiyonu arada çağrılır.
Ham içerikler:
+----+----+----+----+----+----+----+----+
| |
+ 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
Şifrelenmemiş veri (Poly1305 auth etiketleri gösterilmemiş):
+----+----+----+----+----+----+----+----+
| |
+ +
| 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) Çevrimiçi DPI
Bob, olağan Router Info doğrulamasını gerçekleştirmelidir. İmza türünün desteklendiğinden emin olun, imzayı doğrulayın, zaman damgasının sınırlar içinde olduğunu doğrulayın ve gerekli diğer kontrolleri yapın.
Bob, ilk frame’de aldığı Alice’in statik anahtarının Router Info’daki statik anahtarla eşleştiğini doğrulamalıdır. Bob önce Router Info’da eşleşen bir sürüm (v) seçeneğine sahip NTCP veya NTCP2 Router Address aramalıdır. Aşağıdaki Yayınlanmış Router Info ve Yayınlanmamış Router Info bölümlerine bakın.
Bob’un netdb’sinde Alice’in RouterInfo’sunun eski bir sürümü varsa, varsa her ikisinde de statik anahtarın aynı olduğunu doğrulayın ve eski sürüm XXX’den daha eski değilse (aşağıdaki anahtar döndürme zamanına bakın)
Bob, Alice’in statik anahtarının burada eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
Dolgu parametrelerini belirtmek için seçenekler dahil edilmelidir.
Herhangi bir hata durumunda (AEAD, RI, DH, timestamp veya anahtar doğrulama hatası dahil), Bob daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu anormal bir kapatma olmalıdır (TCP RST).
Hızlı el sıkışmayı kolaylaştırmak için, uygulamalar Alice’in üçüncü mesajın tüm içeriğini bir kerede tamponlamasını ve ardından boşaltmasını sağlamalıdır, bu da her iki AEAD çerçevesini de kapsar. Bu, verilerin tek bir TCP paketinde bulunma olasılığını artırır (işletim sistemi veya ara kutular tarafından segmentlenmediği sürece) ve Bob tarafından hep birden alınmasını sağlar. Bu aynı zamanda verimlilik içindir ve rastgele dolgunun etkinliğini garanti etmek içindir.
Message 3 part 2 frame uzunluğu: Bu frame’in uzunluğu (MAC dahil) Alice tarafından message 1’de gönderilir. Padding için yeterli alan bırakma konusundaki önemli notlar için o mesaja bakın.
Mesaj 3 kısım 2 çerçeve içeriği: Bu çerçevenin formatı, veri aşaması çerçevelerinin formatı ile aynıdır, ancak çerçevenin uzunluğu Alice tarafından mesaj 1’de gönderilir. Veri aşaması çerçeve formatı için aşağıya bakınız. Çerçeve aşağıdaki sırada 1 ila 3 blok içermelidir:
- Alice’in Router Info bloğu (zorunlu)
- Seçenekler bloğu (isteğe bağlı)
- Padding bloğu (isteğe bağlı) Bu çerçeve hiçbir zaman başka bir blok türü içermemelidir.
Mesaj 3 bölüm 2 dolgusu, Alice mesaj 3’ün sonuna bir veri fazı çerçevesi (isteğe bağlı olarak dolgu içeren) ekleyip her ikisini birden gönderirse gerekli değildir, çünkü bir gözlemciye tek bir büyük bayt akışı olarak görünecektir. Alice genellikle, her zaman olmasa da, Bob’a gönderecek bir I2NP mesajı olacağından (bu yüzden ona bağlandı), bu verimlilik için ve rastgele dolgunun etkinliğini sağlamak için önerilen uygulamadır.
Hem Message 3 AEAD çerçevesinin (1. ve 2. kısım) toplam uzunluğu 65535 bayttır;
- kısım 48 bayt olduğundan 2. kısım maksimum çerçeve uzunluğu 65487’dir;
- kısım MAC hariç maksimum düz metin uzunluğu 65471’dir.
Key Derivation Function (KDF) (for data phase)
Veri fazı sıfır uzunluklu ilişkili veri girişi kullanır.
KDF, chaining key ck’den iki cipher anahtarı k_ab ve k_ba üretir ve RFC-2104’te tanımlandığı şekilde HMAC-SHA256(key, data) kullanır. Bu, Noise spec’te tam olarak tanımlandığı gibi Split() fonksiyonudur.
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: Aşağıda tanımlandığı gibi, rastgele dolgu dahil Non-noise payload: hiçbiri
Mesaj 3’ün 2. kısmından başlayarak, tüm mesajlar, öne eklenmiş iki baytlık gizlenmiş uzunlukla birlikte kimliği doğrulanmış ve şifrelenmiş bir ChaChaPoly “çerçevesi” içindedir. Tüm dolgu çerçevenin içindedir. Çerçevenin içinde sıfır veya daha fazla “blok” içeren standart bir format bulunur. Her bloğun bir baytlık bir türü ve iki baytlık bir uzunluğu vardır. Türler arasında tarih/saat, I2NP mesajı, seçenekler, sonlandırma ve dolgu bulunur.
Not: Bob, veri aşamasında Alice’e gönderdiği ilk mesajda RouterInfo bilgisini gönderebilir, ancak bunu yapmak zorunda değildir.
(Payload Güvenlik Özellikleri)
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) Çevrimdışı DPI
Verimlilik için ve uzunluk alanının tanımlanmasını en aza indirmek amacıyla, uygulamalar gönderenin uzunluk alanı ve AEAD çerçevesi dahil olmak üzere veri mesajlarının tüm içeriğini arabelleğe alıp daha sonra bir kerede boşaltmasını sağlamalıdır. Bu, verilerin tek bir TCP paketinde bulunma olasılığını artırır (işletim sistemi veya ara kutular tarafından bölümlenmedikçe) ve karşı taraf tarafından aynı anda alınmasını sağlar. Bu aynı zamanda verimlilik için ve rastgele dolgunun etkinliğini garanti etmek içindir.
Router, AEAD hatası durumunda oturumu sonlandırmayı seçebilir veya iletişim kurmaya devam etmeye çalışabilir. Devam etme durumunda, router tekrarlanan hatalardan sonra sonlandırmalıdır.
SipHash obfuscated length
Referans: SipHash
Her iki taraf da handshake’i tamamladıktan sonra, ChaChaPoly “frame"lerinde şifrelenen ve doğrulanan yükleri aktarırlar.
Her frame, iki baytlık bir uzunluk değeri ile başlar, big endian formatında. Bu uzunluk, MAC dahil olmak üzere takip eden şifrelenmiş frame baytlarının sayısını belirtir. Akışta tanımlanabilir uzunluk alanlarının iletilmesini önlemek için, frame uzunluğu veri aşaması KDF’sinden başlatılan SipHash’ten türetilen bir maske ile XORlanarak gizlenir. İki yönün KDF’den benzersiz SipHash anahtarları ve IV’leri olduğunu unutmayın.
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].
Alıcı aynı SipHash anahtarlarına ve IV’ye sahiptir. Uzunluğun çözülmesi, uzunluğu gizlemek için kullanılan maskeyi türeterek ve çerçevenin uzunluğunu elde etmek için kesilmiş özeti XOR’layarak yapılır. Çerçeve uzunluğu, MAC dahil olmak üzere şifrelenmiş çerçevenin toplam uzunluğudur.
Gelecekteki çalışmalar
- Eğer unsigned long integer döndüren bir SipHash kütüphane fonksiyonu kullanıyorsanız, en az anlamlı iki baytı Mask olarak kullanın. Long integer’ı bir sonraki IV’ye little endian olarak dönüştürün.
Kimliği Doğrulanmış Şifreleme
+----+----+----+----+----+----+----+----+
|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
Şifrelenmiş çerçevede sıfır veya daha fazla blok bulunur. Her blok bir baytlık tanımlayıcı, iki baytlık uzunluk ve sıfır veya daha fazla bayt veri içerir.
Genişletilebilirlik için, alıcılar bilinmeyen tanımlayıcılara sahip blokları görmezden gelmeli ve bunları dolgu olarak değerlendirmelidir.
Şifrelenmiş veri maksimum 65535 bayttır ve bu 16-baytlık kimlik doğrulama başlığını içerir, dolayısıyla maksimum şifrelenmemiş veri 65519 bayttır.
(Poly1305 kimlik doğrulama etiketi gösterilmemiştir):
+----+----+----+----+----+----+----+----+
|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
Handshake mesajı 3 bölüm 2’de sıralama şu şekilde olmalıdır: RouterInfo, ardından varsa Options, ardından varsa Padding. Başka hiçbir bloğa izin verilmez.
Veri fazında, aşağıdaki gereksinimler dışında sıralama belirtilmemiştir: Padding, mevcut ise, son blok olmalıdır. Termination, mevcut ise, Padding hariç son blok olmalıdır.
Tek bir çerçevede birden fazla I2NP bloğu bulunabilir. Tek bir çerçevede birden fazla Padding bloğuna izin verilmez. Diğer blok türleri muhtemelen tek bir çerçevede birden fazla bloğa sahip olmayacaktır, ancak bu yasaklanmamıştır.
AEAD Hata İşleme
Zaman senkronizasyonu için özel durum:
+----+----+----+----+----+----+----+
| 0 | 4 | timestamp |
+----+----+----+----+----+----+----+
blk :: 0
size :: 2 bytes, big endian, value = 4
timestamp :: Unix timestamp, unsigned seconds.
Wraps around in 2106
Anahtar Türetme Fonksiyonu (KDF) (handshake mesajı 1 için)
Güncellenmiş seçenekleri geçir. Seçenekler şunları içerir: Minimum ve maksimum padding.
Seçenekler bloğu değişken uzunlukta olacaktır.
+----+----+----+----+----+----+----+----+
| 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
- Seçenekler formatı henüz belirlenmemiştir.
- Seçenekler müzakeresi henüz belirlenmemiştir.
RouterInfo
Alice’in RouterInfo’sunu Bob’a geçir. Handshake mesajı 3 bölüm 2’de kullanılır. Alice’in RouterInfo’sunu Bob’a veya Bob’unkini Alice’e geçir. Veri fazında isteğe bağlı olarak kullanılır.
+----+----+----+----+----+----+----+----+
| 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
Veri aşamasında kullanıldığında, alıcı (Alice veya Bob) bunun başlangıçta gönderilen (Alice için) veya gönderilen (Bob için) aynı Router Hash olduğunu doğrulamalıdır. Ardından, bunu yerel bir I2NP DatabaseStore Mesajı olarak ele alın. İmzayı doğrulayın, daha güncel zaman damgasını doğrulayın ve yerel netdb’de saklayın. Flag bit 0’ı 1 ise ve alıcı taraf floodfill ise, bunu sıfır olmayan yanıt token’ı olan bir DatabaseStore Mesajı olarak ele alın ve en yakın floodfill’lere yayın.
Router Info gzip ile sıkıştırılmaz (DatabaseStore Mesajında olduğu gibi değil, orada sıkıştırılır)
Flooding, RouterInfo içinde yayınlanmış RouterAddress’ler olmadıkça talep edilmemelidir. Alıcı router, içinde yayınlanmış RouterAddress’ler olmadıkça RouterInfo’yu flood etmemelidir.
Uygulayıcılar, bir blok okunurken hatalı biçimlendirilmiş veya kötü niyetli verinin okumaların bir sonraki bloğa taşmasına neden olmayacağını garanti etmelidir.
Bu protokol, RouterInfo’nun alındığına, depolandığına veya flooda edildiğine dair bir onay sağlamaz (ne handshake ne de veri aşamasında). Eğer onay isteniyorsa ve alıcı floodfill ise, gönderici bunun yerine reply token ile standart bir I2NP DatabaseStoreMessage göndermelidir.
Issues
Veri fazında da kullanılabilir, bir I2NP DatabaseStoreMessage yerine. Örneğin, Bob bunu veri fazını başlatmak için kullanabilir.
Bu, DatabaseStoreMessages için genel bir yedek olarak, örneğin floodfill’ler tarafından flooding için, orijinli router dışındaki router’lar için RI içermesine izin verilir mi?
Anahtar Türetme Fonksiyonu (KDF) (handshake mesaj 2 ve mesaj 3 bölüm 1 için)
Değiştirilmiş başlığa sahip tek bir I2NP mesajı. I2NP mesajları bloklar arasında veya ChaChaPoly çerçeveleri arasında parçalanmamalıdır.
Bu, standart NTCP I2NP başlığından ilk 9 baytı kullanır ve başlığın son 7 baytını aşağıdaki gibi kaldırır: sona erme süresini 8 bayttan 4 bayta kısaltır, 2 baytlık uzunluğu kaldırır (blok boyutu - 9 kullanır) ve tek baytlık SHA256 sağlama toplamını kaldırır.
+----+----+----+----+----+----+----+----+
| 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
- Uygulayıcılar, bir blok okunurken hatalı biçimlendirilmiş veya kötü niyetli verinin okumaların bir sonraki bloka taşmasına neden olmayacağından emin olmalıdır.
2) SessionCreated
Noise açık bir sonlandırma mesajı önerir. Orijinal NTCP’de böyle bir mesaj yoktur. Bağlantıyı kes. Bu, çerçevedeki son padding olmayan blok olmalıdır.
+----+----+----+----+----+----+----+----+
| 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
Tüm nedenler gerçekte kullanılmayabilir, uygulama bağımlıdır. Handshake hataları genellikle TCP RST ile kapatmayla sonuçlanır. Yukarıdaki handshake mesaj bölümlerindeki notlara bakın. Listelenen ek nedenler tutarlılık, kayıt tutma, hata ayıklama veya politika değişiklikleri için vardır.
Padding
Bu, AEAD çerçeveleri içindeki dolgu için kullanılır. Mesaj 1 ve 2 için dolgular AEAD çerçevelerinin dışındadır. Mesaj 3 ve veri aşaması için tüm dolgular AEAD çerçevelerinin içindedir.
AEAD içindeki padding, müzakere edilen parametrelere kabaca uymalıdır. Bob, istenen tx/rx min/max parametrelerini mesaj 2’de gönderdi. Alice, istenen tx/rx min/max parametrelerini mesaj 3’te gönderdi. Güncellenmiş seçenekler veri aşaması sırasında gönderilebilir. Yukarıdaki seçenekler bloğu bilgilerine bakın.
Mevcut ise, bu frame’deki son blok olmalıdır.
+----+----+----+----+----+----+----+----+
|254 | size | padding |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 254
size :: 2 bytes, big endian, size of padding to follow
padding :: random data
Notes
- Padding stratejileri TBD.
- Minimum padding TBD.
- Yalnızca padding içeren frame’ler izin verilir.
- Padding varsayılanları TBD.
- Padding parametresi müzakeresi için options bloğuna bakın
- Min/max padding parametreleri için options bloğuna bakın
- Noise mesajları 64KB ile sınırlar. Daha fazla padding gerekirse, birden fazla frame gönderin.
- Router’ın müzakere edilmiş padding ihlali durumundaki tepkisi implementasyona bağlıdır.
Other block types
Uygulamalar, mesaj 3 bölüm 2’de bilinmeyen blokların izin verilmediği durumlar dışında, ileriye dönük uyumluluk için bilinmeyen blok tiplerini görmezden gelmelidir.
Future work
- Dolgu uzunluğu ya mesaj bazında karar verilmeli ve uzunluk dağılımı tahminleri kullanılmalı, ya da rastgele gecikmeler eklenmelidir. Bu karşı önlemler DPI’ye karşı direnç sağlamak için dahil edilmelidir, çünkü mesaj boyutları aksi takdirde taşıma protokolü tarafından I2P trafiğinin taşındığını ortaya çıkarabilir. Tam dolgu şeması gelecekteki çalışma alanıdır, Ek A bu konuda daha fazla bilgi sağlar.
5) Termination
Bağlantılar normal veya anormal TCP socket kapanışı yoluyla sonlandırılabilir, ya da Noise’ın önerdiği gibi açık bir sonlandırma mesajı ile sonlandırılabilir. Açık sonlandırma mesajı yukarıdaki veri aşamasında tanımlanmıştır.
Normal veya anormal herhangi bir sonlanma durumunda, routerlar bellekteki tüm geçici verileri sıfırlamalıdır; bunlara handshake geçici anahtarları, simetrik şifreleme anahtarları ve ilgili bilgiler dahildir.
Published Router Info
Handshake mesajı 3 bölüm 1 için şifreleme, mesaj 2 KDF kullanarak)
Yayınlanan RouterAddress (RouterInfo’nun bir parçası) “NTCP” veya “NTCP2” protokol tanımlayıcısına sahip olacaktır.
RouterAddress, mevcut NTCP protokolünde olduğu gibi “host” ve “port” seçeneklerini içermelidir.
RouterAddress, NTCP2 desteğini belirtmek için üç seçenek içermelidir:
s=(Base64 key) Bu RouterAddress için mevcut Noise statik genel anahtarı (s). Standart I2P Base 64 alfabesi kullanılarak Base 64 ile kodlanmış. İkili formatta 32 byte, Base 64 kodlu olarak 44 byte, little-endian X25519 genel anahtarı.
i=(Base64 IV) Bu RouterAddress için mesaj 1’deki X değerini şifrelemek için kullanılan mevcut IV. Standart I2P Base 64 alfabesi kullanılarak Base 64 kodlanmış. İkili formatta 16 bayt, Base 64 kodlanmış olarak 24 bayt, big-endian.
v=2 Mevcut sürüm (2). “NTCP” olarak yayınlandığında, sürüm 1 için ek destek ima edilir. Gelecek sürümler için destek virgülle ayrılmış değerlerle olacak, örneğin v=2,3 Uygulama, virgül varsa birden fazla sürüm dahil olmak üzere uyumluluğu doğrulamalıdır. Virgülle ayrılmış sürümler sayısal sırada olmalıdır.
Alice, NTCP2 protokolünü kullanarak bağlanmadan önce üç seçeneğin de mevcut ve geçerli olduğunu doğrulamalıdır.
“s”, “i”, ve “v” seçenekleri ile “NTCP” olarak yayınlandığında, router o host ve port üzerinde hem NTCP hem de NTCP2 protokolleri için gelen bağlantıları kabul etmeli ve protokol sürümünü otomatik olarak algılamalıdır.
“s”, “i” ve “v” seçenekleri ile “NTCP2” olarak yayınlandığında, router o host ve port üzerinde yalnızca NTCP2 protokolü için gelen bağlantıları kabul eder.
Eğer bir router hem NTCP1 hem de NTCP2 bağlantılarını destekliyorsa ancak gelen bağlantılar için otomatik sürüm algılaması uygulamıyorsa, hem “NTCP” hem de “NTCP2” adreslerini duyurmalı ve NTCP2 seçeneklerini yalnızca “NTCP2” adresine dahil etmelidir. Router, NTCP2’nin tercih edilmesi için “NTCP2” adresinde “NTCP” adresinden daha düşük bir maliyet değeri (daha yüksek öncelik) ayarlamalıdır.
Aynı RouterInfo içinde birden fazla NTCP2 RouterAddress (“NTCP” veya “NTCP2” olarak) yayınlanırsa (ek IP adresleri veya portlar için), aynı portu belirten tüm adresler özdeş NTCP2 seçenekleri ve değerleri içermelidir. Özellikle, tümü aynı statik anahtar ve iv içermelidir.
Anahtar Türetme Fonksiyonu (KDF) (handshake mesajı 3 bölüm 2 için)
Alice gelen bağlantılar için NTCP2 adresini (“NTCP” veya “NTCP2” olarak) yayınlamazsa, Bob’un 3. mesajın 2. kısmında Alice’in RouterInfo’sunu aldıktan sonra anahtarı doğrulayabilmesi için yalnızca statik anahtarını ve NTCP2 sürümünü içeren bir “NTCP2” router adresi yayınlamalıdır.
s=(Base64 anahtar) Yayınlanmış adresler için yukarıda tanımlandığı gibi.
v=2 Yukarıda yayınlanan adresler için tanımlandığı gibi.
Bu router adresi “i”, “host” veya “port” seçeneklerini içermeyecektir, çünkü bunlar giden NTCP2 bağlantıları için gerekli değildir. Bu adres için yayınlanan maliyet kesinlikle önemli değildir, çünkü sadece gelen bağlantılar içindir; ancak, maliyet diğer adreslerden daha yüksek (daha düşük öncelik) olarak ayarlanırsa diğer router’lara yardımcı olabilir. Önerilen değer 14’tür.
Alice ayrıca mevcut yayımlanmış bir “NTCP” adresine sadece “s” ve “v” seçeneklerini ekleyebilir.
3) SessionConfirmed
RouterInfo’ların önbelleğe alınması nedeniyle, router’lar statik public key veya IV’yi router çalışırken, yayınlanmış bir adres olsun ya da olmasın, döndürmemelidir. Router’lar bu key ve IV’yi ani yeniden başlatma sonrasında yeniden kullanım için kalıcı olarak depolamalıdır, böylece gelen bağlantılar çalışmaya devam edecek ve yeniden başlatma süreleri açığa çıkmayacaktır. Router’lar başlangıçta önceki kapalı kalma süresinin hesaplanabilmesi için son kapatma zamanını kalıcı olarak depolamalı veya başka şekilde belirlemelidir.
Yeniden başlatma zamanlarının açığa çıkması konusundaki endişeler doğrultusunda, router’lar daha önce bir süre (en az birkaç saat) kapalı kalmışlarsa başlangıçta bu anahtarı veya IV’yi değiştirebilirler.
Router yayınlanmış herhangi bir NTCP2 RouterAddress’e sahipse (NTCP veya NTCP2 olarak), rotasyon öncesi minimum kesinti süresi çok daha uzun olmalıdır, örneğin bir ay, yerel IP adresi değişmediği veya router “rekey” yapmadığı sürece.
Router’ın yayınlanmış SSU RouterAddress’leri varsa, ancak NTCP2’si yoksa (NTCP veya NTCP2 olarak) rotasyondan önceki minimum kapalı kalma süresi daha uzun olmalıdır, örneğin bir gün, yerel IP adresi değişmedikçe veya router “rekey” yapmadıkça. Bu, yayınlanmış SSU adresinin introducer’ları olsa bile geçerlidir.
Router’ın yayınlanmış herhangi bir RouterAddress’i (NTCP, NTCP2, veya SSU) yoksa, router “rekey” yapmadığı sürece, IP adresi değişse bile rotasyon öncesi minimum kesinti süresi iki saat kadar kısa olabilir.
Router farklı bir Router Hash’e “rekey” yaparsa, yeni bir noise anahtarı ve IV de üretmelidir.
Implementasyonlar, statik public key veya IV değişikliğinin, eski bir RouterInfo önbelleğe almış router’lardan gelen NTCP2 bağlantılarını engelleyeceğinin farkında olmalıdır. RouterInfo yayınlama, tünel eş seçimi (hem OBGW hem de IB en yakın hop dahil), sıfır-hop tünel seçimi, transport seçimi ve diğer implementasyon stratejileri bunu dikkate almalıdır.
IV rotasyonu, anahtar rotasyonu ile aynı kurallara tabidir; ancak IV’ler yalnızca yayınlanan RouterAddress’lerde bulunur, bu nedenle gizli veya güvenlik duvarı arkasındaki router’lar için IV yoktur. Herhangi bir şey değişirse (sürüm, anahtar, seçenekler?) IV’nin de değişmesi önerilir.
Not: Ağ sağlığını sağlamak ve orta düzeyde bir süre çevrimdışı olan bir router’ın yeniden seed işlemi yapmasını önlemek için, yeniden anahtar oluşturma öncesi minimum kesinti süresi değiştirilebilir.
Identity Hiding
İnkâr edilebilirlik bir hedef değildir. Yukarıdaki genel bakışa bakın.
Her bir desene, başlatanın statik genel anahtarına ve yanıtlayanın statik genel anahtarına sağlanan gizlilik düzeyini açıklayan özellikler atanır. Temel varsayımlar, geçici özel anahtarların güvenli olduğu ve tarafların, güvenmedikleri diğer taraftan statik genel anahtar almaları durumunda el sıkışmayı iptal ettikleridir.
Bu bölüm yalnızca handshake’lerdeki statik genel anahtar alanları aracılığıyla kimlik sızıntısını ele almaktadır. Tabii ki, Noise katılımcılarının kimlikleri payload alanları, trafik analizi veya IP adresleri gibi metadata dahil olmak üzere başka yollarla da ifşa olabilir.
Alice: (8) Kimliği doğrulanmış bir tarafa ileri gizlilik ile şifrelenmiş.
Bob: (3) İletilmez, ancak pasif bir saldırgan yanıtlayıcının özel anahtarı için adayları kontrol edebilir ve adayın doğru olup olmadığını belirleyebilir.
Bob statik genel anahtarını netDb’de yayınlar. Alice yayınlayabilir ya da yayınlamayabilir?
Issues
- Bob statik anahtarını değiştirirse, bir “XX” desenine geri dönebilir mi?
Noise Protocol Framework
“NTCP” olarak yayınlandığında, router gelen bağlantılar için protokol sürümünü otomatik olarak algılamalıdır.
Bu tespit uygulama-bağımlıdır, ancak burada bazı genel rehberlik bulunmaktadır.
Gelen bir NTCP bağlantısının sürümünü tespit etmek için Bob şu şekilde ilerler:
En az 64 bayt bekleyin (minimum NTCP2 mesaj 1 boyutu)
Alınan ilk veri 288 veya daha fazla bayt ise, gelen bağlantı sürüm 1’dir.
288 baytten az ise, ya
Daha fazla veri için kısa bir süre bekle (yaygın NTCP2 benimseniminden önce iyi bir strateji) en az toplam 288 alınmışsa, bu NTCP 1’dir.
İlk çözme aşamalarını sürüm 2 olarak deneyin, başarısız olursa daha fazla veri için kısa bir süre bekleyin (yaygın NTCP2 benimsenmesinden sonra iyi bir strateji)
- 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
NTCP 1 üzerinde aktif TCP segmentasyon saldırıları tespit edersek değişiklikler veya ek stratejiler önerilir olabileceğini unutmayın.
Hızlı versiyon tespiti ve handshake işlemini kolaylaştırmak için, uygulamalar Alice’in padding dahil olmak üzere ilk mesajın tüm içeriğini arabelleğe almasını ve ardından bir seferde temizlemesini sağlamalıdır. Bu, verilerin tek bir TCP paketinde bulunma olasılığını artırır (işletim sistemi veya middlebox’lar tarafından bölümlenmedikçe) ve Bob tarafından aynı anda alınmasını sağlar. Bu aynı zamanda verimlilik için ve rastgele padding’in etkinliğini sağlamak içindir. Bu, hem NTCP hem de NTCP2 handshake işlemleri için geçerlidir.
Çerçeveye Eklemeler
Alice ve Bob’un her ikisi de NTCP2’yi destekliyorsa, Alice NTCP2 ile bağlanmalıdır.
Alice herhangi bir nedenle Bob’a NTCP2 kullanarak bağlanamadığında, bağlantı başarısız olur. Alice NTCP 1 kullanarak yeniden deneyemez.
Bob anahtarlarını değiştirirse XX desenine geri dönüş? Bu, önüne eklenmiş bir tür baytı gerektirir mi?
Alice yeniden bağlandığında, Bob’un hala onun statik anahtarına sahip olduğunu varsayarak KK desenine “ileriye doğru geçiş” yapılsın mı? Bu herhangi bir gidiş-dönüş tasarrufu sağlamaz ve XK için 3’e kıyasla 4 DH turu kullanır. Muhtemelen hayır.
KK(s, rs):
-> s
<- s
...
-> e, es, ss
<- e, ee, se
I2P için Yeni Kriptografik İlkeller
Bu bölüm, saldırganların yalnızca dolgulanmış mesajların uzunluğunu gözlemleyerek, dolgulanmamış mesajların uzunluğunun olasılık dağılımını keşfetmelerine olanak tanıyan, tipik doldurma şemalarına yönelik bir saldırıyı tartışmaktadır. N, dolgulanmamış bayt sayısını tanımlayan bir rastgele değişken olsun ve P de benzer şekilde doldurma baytlarının sayısı için olsun. Toplam mesaj boyutu o zaman N + P’dir.
n boyutunda padding uygulanmamış bir boyut için, bir padding şemasında en az P_min(n) >= 0 ve en fazla P_max(n) >= P_min(n) bayt padding eklendiğini varsayalım. Açık şema, rastgele olarak düzgün şekilde seçilen P uzunluğunda padding kullanır:
Pr[P = p | N = n] = 1 / (P_max(n) - P_min(n)) if P_min(n) <= p <= P_max(n),
0 otherwise.
Basit bir padding şeması, sadece dolgulu mesajın boyutunun N_max değerini aşmamasını sağlardı:
P_max(n) = N_max - n, n <= N_max
P_min(n) = 0.
Ancak, bu padding uygulanmamış uzunluk hakkında bilgi sızdırır.
Bir saldırgan Pr[x <= N + P <= y] değerini kolayca tahmin edebilir, örneğin bir histogram kullanarak.
- Bundan,
Pr[n_1 <= N <= n_2]değerini tahmin etmeye de çalışabilir, gerçekten de:
Pr[N + P = m] = Σ_n Pr[N = n] Pr[P = m - n | N = n].
Basit şemada,
Pr[N + P = m] = Σ_{n <= m} Pr[N = n] / (N_max - n).
Yukarıdaki hesaplamayı yapmadan önce de oldukça açık olan şu ki, bu durum Pr[N = n] hakkında bilgi sızdırır: paketlerin uzunluğu hemen hemen her zaman m’den fazlaysa, N + P <= m durumu hemen hemen hiç gözlemlenmeyecektir. Minimum mesaj uzunluğunu gözlemleyebilmenin tek başına bir sorun olarak değerlendirilebilmesine rağmen, bu en büyük sorun değildir.
Daha büyük bir sorun, Pr[N = n]‘nin tam olarak belirlenebilir olmasıdır:
Pr[N + P = m] - Pr[N + P = m-1] = Pr[N = m] / (N_max - m),
yani
Pr[N = n] = (N_max - n)(Pr[N + P = n] - Pr[N + P = n - 1])
NTCP2’yi ayırt etmek için, saldırgan aşağıdakilerden herhangi birini kullanabilir:
Pozitif tamsayılar k için
Pr[kB <= N <= (k + 1)B - 1]değerini tahmin edin. NTCP2 için her zaman sıfır olacaktır.Pr[N = kB]‘yi tahmin edin ve standart bir I2P profili ile karşılaştırın.
Bu basit saldırı, dolgu eklenmemiş mesajların boyut dağılımını gizlemeye çalışan padding’in amacını kısmen ortadan kaldırır. Saldırganın protokolü ayırt edebilmek için gözlemlemesi gereken mesaj miktarı, istenen doğruluk düzeyine ve pratikte ortaya çıkan minimum ve maksimum dolgu eklenmemiş mesaj boyutlarına bağlıdır. Saldırganın hedefin kullandığı belirli port’tan gelen ve giden tüm trafiği kullanabileceği için çok sayıda mesaj toplamasının kolay olduğunu unutmayın.
Bazı formlarda (örneğin Pr[kB <= N <= (k + 1)B - 1] tahmini) saldırı sadece birkaç bayt bellek gerektirir (bir tam sayı yeterlidir) ve böyle bir saldırının biraz daha gelişmiş ancak yine de standart olan birçok DPI çerçevesine dahil edilebileceği tartışılabilir.
Bu öneri aşağıdaki karşı önlemlerden birinin kullanılmasını önerir:
N’nin (tahmini) dağılımını dikkate alan ve tekdüze olmayan bir dolgu uzunluğu dağılımı kullanan alternatif bir dolgu şeması geliştirin. İyi bir dolgu şeması muhtemelen mesaj başına blok sayısının histogramını tutmayı gerektirir.
Mesajların (rastgele boyutlu) parçaları arasına rastgele gecikmeler ekle.
İkinci seçenek genellikle daha çok tercih edilir, çünkü aynı zamanda akış analizine karşı bir önlem olarak kullanılabilir. Ancak, bu tür gecikmeler NTCP2 protokolünün kapsamı dışında kalabilir, bu nedenle aynı zamanda uygulanması daha kolay olan ilk seçenek bunun yerine tercih edilebilir.
İşleme yükü tahmini
Zamanlama tabanlı DPI direnci (mesajlar arası zamanlama/gecikmeler implementasyona bağlı olabilir; mesaj içi gecikmeler rastgele padding gönderilmeden önce dahil olmak üzere herhangi bir noktada eklenebilir). Yapay gecikmeler (obfs4’ün IAT veya inter-arrival time dediği) protokolün kendisinden bağımsızdır.