Ez a cikk az MTProto végpontok közötti titkosításáról haladó felhasználók számára készült.Ha többet szeretne megtudni a kevésbé megfélemlítő forrásból származó titkos csevegésekről, kérjük, olvassa el az Általános GYIK-t.

vegye figyelembe, hogy a 4.6 verziótól kezdve a nagyobb Telegram ügyfelek MTProto 2.0-t használnak.Az MTProto V. 1.0 elavult, és jelenleg fokozatosan megszűnik.

a titkos Csevegések olyan személyes Csevegések, amelyekben az üzeneteket csak a csevegés résztvevői tartják titkosítva. Vegye figyelembe, hogy ezeknek a végpontok közötti titkosított titkos csevegéseknek a sémája eltér a felhőbeli csevegésekhez használtaktól:

Megjegyzés Az MTProto 2.0-hoz

Ez a cikk az MTProto protokoll 2.0-s verziójának végpontok közötti titkosítási rétegét ismerteti.A fő különbségek az 1.0 verziótól (itt referenciaként ismertetjük) a következők:

• SHA-256-ot használunk az SHA-1 helyett;
• a kitöltő bájtok részt vesznek az msg_key kiszámításában;
• az msg_key nem csak a titkosítandó üzenettől függ, hanem a titkos csevegőkulcs egy részétől is;
• 12..1024 kitöltő bájt kerül felhasználásra a 0 helyett..15 kitöltő bájt V. 1.0.

Lásd még: MTProto 2.0: Cloud Chats, szerver-kliens titkosítás

kulcsgenerálás

a kulcsokat a Diffie-Hellman protokoll segítségével állítják elő.

nézzük meg a következő forgatókönyvet: az a felhasználó end-to-end titkosított kommunikációt szeretne kezdeményezni a B felhasználóval.

Kérés küldése

a felhasználó végrehajtja az üzeneteket.getDhConfig a Diffie-Hellman paraméterek eléréséhez: prím oés egy magas rendű elem g.

ennek a módszernek a végrehajtása minden új kulcsgenerálási eljárás előtt létfontosságú. Érdemes gyorsítótárazni a paraméterek értékeit a verzióval együtt annak elkerülése érdekében, hogy minden alkalommal meg kell kapnia az összes értéket. Ha az ügyfélen tárolt verzió még mindig naprakész, a szerver visszaadja a konstruktor üzeneteket.dhconfignotmódosított.

az ügyféltől elvárják, hogy ellenőrizze, hogy p egy biztonságos 2048 bites prímszám-e (ami azt jelenti, hogy p és (p-1)/2 is prímszám, és hogy 2^2047< p< 2^2048), és hogy g generál egy ciklikus alcsoportot a prímrendből (p-1) / 2, azaz. egy másodfokú maradék mod o. mivel g mindig egyenlő 2, 3, 4, 5, 6 vagy 7, Ezt könnyen meg lehet tenni a másodfokú viszonossági törvény alkalmazásával, egyszerű feltételt adva p mod 4G-nevezetesen, p mod 8 = 7 g = 2 esetén; p Mod 3 = 2 g = 3 esetén; nincs további feltétel g = 4 esetén; p mod 5 = 1 vagy 4 g = 5 esetén; p mod 24 = 19 vagy 23 g = 6 esetén; és p mod 7 = 3, 5 vagy 6 g = 7 esetén. Miután a kliens ellenőrizte a g-t és a p-t, érdemes gyorsítótárazni az eredményt, hogy a jövőben elkerüljük a hosszadalmas számítások megismétlését. Lehet, hogy ez a gyorsítótár meg van osztva az engedélyezési kulcs generálásához használt gyorsítótárral.

Ha az ügyfél nem megfelelő véletlenszám-generátorral rendelkezik, akkor érdemes átadni a random_length paramétert (random_length> 0), így a szerver létrehozza a saját véletlenszerű sorrendjét, a megfelelő hosszúságú véletlenszerűt.Fontos: a kiszolgáló véletlen sorrendjének nyers formában történő használata nem biztonságos. Ezt össze kell kapcsolni egy klienssorozattal, például egy azonos hosszúságú kliens véletlenszám generálásával (client_random) és a final_random := random XOR client_randomhasználatával.

Az a kliens kiszámít egy 2048 bites a számot (elegendő entrópiával vagy a szerver véletlenszerűségével; lásd fent), és végrehajtja az üzeneteket.requestEncryption átadás után g_a := pow(g, a) mod dh_prime.

A B felhasználó megkapja az Update updateEncryption frissítést az összes kapcsolódó engedélyezési kulcshoz (minden engedélyezett eszközhöz) az encryptedChatRequested csevegőkonstruktorral. A felhasználónak meg kell mutatnia az a felhasználóval kapcsolatos alapvető információkat, és fel kell kérni a kérés elfogadására vagy elutasítására.

mindkét kliensnek ellenőriznie kell, hogy g, g_a és g_b nagyobbak-e, mint egy és kisebbek, mint p-1. Javasoljuk, hogy ellenőrizze, hogy g_a és g_b között 2^{2048-64} és p-2^{2048-64} is.

kérés elfogadása

miután a B Felhasználó megerősítette egy titkos csevegés létrehozását az A-val az ügyfél felületén, a B ügyfél naprakész konfigurációs paramétereket is kap a Diffie-Hellman módszerhez. Ezt követően véletlenszerű 2048 bites számot generál, b, az a-hoz hasonló szabályok felhasználásával.

miután megkapta a g_a-t az encryptedchatrequested frissítésből, azonnal létrehozhatja a végső megosztott kulcsot: key = (pow(g_a, b) mod dh_prime). Ha a kulcs hossza < 256 bájt, adjon hozzá több vezető nulla bájtot kitöltésként — úgy, hogy a kulcs pontosan 256 bájt hosszú legyen. Ujjlenyomata, key_fingerprint, megegyezik az SHA1 (kulcs) 64 utolsó bitjével.

1. megjegyzés: ebben a konkrét esetben az SHA1-et itt is használják MTProto 2.0 titkos csevegésekhez.

2. megjegyzés: ezt az ujjlenyomatot józansági ellenőrzésként használják a kulcscsere-eljáráshoz, hogy észleljék a hibákat az ügyfélszoftver fejlesztésekor-ez nem kapcsolódik az ügyfeleken a titkos Csevegések külső hitelesítésének eszközeként használt kulcsmegjelenítéshez. A kliensek kulcsmegjelenítéseit az első 128 bit SHA1(belső kulcs), majd az első 160 bit SHA256(a titkos csevegés 46.rétegre történő frissítésekor használt kulcs) felhasználásával állítják elő.

A B kliens végrehajtja az üzeneteket.acceptEncryption átadása után g_b := pow(g, b) mod dh_prime és key_fingerprint.

az összes kliens B engedélyezett eszközök, kivéve a jelenlegi, updateEncryption frissítéseket küld a kivitelező encryptedChatDiscarded. Ezt követően az egyetlen eszköz, amely képes lesz hozzáférni a titkos csevegéshez, a B eszköz, amely hívást indított az üzenetekre.elfogadom a titkosítást.

Az a felhasználó egy updateEncryption frissítést küld a constructor encryptedChat segítségével a csevegést kezdeményező engedélyezési kulcshoz.

a frissítésből származó g_b segítségével az a kliens kiszámíthatja a megosztott kulcsot is key = (pow(g_b, a) mod dh_prime). Ha a kulcs hossza < 256 bájt, adjon hozzá több vezető nulla bájtot kitöltésként — úgy, hogy a kulcs pontosan 256 bájt hosszú legyen. Ha a fogadott kulcs ujjlenyomata megegyezik a titkosítottalchat, a bejövő üzenetek elküldhetők és feldolgozhatók. Ellenkező esetben üzenetek.a discardEncryption programot végre kell hajtani, és a felhasználót értesíteni kell.

Perfect Forward Secrecy

annak érdekében, hogy a korábbi kommunikáció biztonságos, hivatalos Telegram ügyfelek kezdeményezi újra beírja, ha egy kulcsot használtak visszafejteni és titkosítani több mint 100 üzenetek, vagy már használatban több mint egy hétig, feltéve, hogy a kulcs már titkosítására használt legalább egy üzenetet. A régi kulcsokat ezután biztonságosan eldobják, és nem lehet rekonstruálni, még akkor sem, ha hozzáférnek a jelenleg használt új kulcsokhoz.

az újra-kulcsozási protokollt ebben a cikkben részletesebben ismertetjük: tökéletes továbbítási titoktartás titkos csevegésekben.

Felhívjuk figyelmét, hogy az ügyfélnek támogatnia kell a titkos Csevegések továbbítását, hogy kompatibilis legyen a hivatalos Telegram ügyfelekkel.

üzenetek küldése és fogadása titkos csevegésben

kimenő üzenetek Sorosítása és titkosítása

létrejön egy DecryptedMessage típusú TL objektum, amely az üzenetet egyszerű szövegben tartalmazza. A visszamenőleges kompatibilitás érdekében az objektumot a decryptedMessageLayer konstruktorba kell csomagolni a támogatott réteg jelzésével (46-tól kezdve).

a végpontok közötti titkosított üzenetek tartalmának TL-sémája itt érhető el “

a kapott konstrukció bájtok tömbjeként van sorosítva általános TL szabályok használatával. A kapott tömböt 4 bájt előzi meg, amely tartalmazza a tömb hosszát, nem számítva ezt a 4 bájtot.

a bájttömb 12-1024 véletlenszerű kitöltési bájttal van kitöltve, hogy hossza osztható legyen 16 bájttal. (A régebbi MTProto 1.0 titkosításban csak 0-15 kitöltő bájtot használtak.)

Üzenetkulcs, msg_key, az előző lépésben kapott adatok SHA256 középső bitjeként kerül kiszámításra, amelyet a megosztott kulcskulcs 32 bájtja ír elő. (A régebbi MTProto 1.0 titkosításhoz az msg_key-t másképp számítottuk ki, mint az előző lépésekben kapott adatok 128 alsó SHA1 bitjét, kivéve a kitöltő bájtokat.)

az MTProto 2.0 esetében az AES kulcs aes_key és inicializáló vektor aes_iv számítása ( a kulcs a kulcs generálása során kapott megosztott kulcs) a következőképpen történik:

• msg_key_large = SHA256 (substr (kulcs, 88 + x, 32) + sima szöveg + random_padding);
• msg_key = substr (msg_key_large, 8, 16);
• sha256_a = SHA256 (msg_key + substr (kulcs, x, 36));
• sha256_b = SHA256 (substr (kulcs, 40+x, 36) + msg_key);
• aes_key = substr (sha256_a, 0, 8) + alcsoport (sha256_b, 8, 16) + alcsoport (sha256_a, 24, 8);
• aes_iv = alcsoport (sha256_b, 0, 8) + alcsoport (sha256_a, 8, 16) + alcsoport (sha256_b, 24, 8);

az MTProto 2.0, x=0 esetében üzenetek a titkos csevegés kezdeményezőjétől, x=8 az ellenkező irányú üzenetekhez.

az elavult MTProto 1 esetében.0, msg_key, aes_key és aes_iv másképp lettek kiszámítva (lásd ezt a dokumentumot referenciaként).

Az adatok titkosítása egy 256 bites kulccsal, aes_keyés egy 256 bites inicializálási vektor, AES-iv, AES-256 titkosítással, végtelen garble kiterjesztéssel (IGE). Titkosítási kulcs ujjlenyomat key_fingerprint és az üzenet kulcs msg_key adunk a tetején a kapott bájt tömb.

a titkosított adatok egy üzenetbe vannak beágyazva.sendEncrypted API hívást, majd át távirat szerver szállítás a másik fél a titkos Chat.

frissítés MTProto 2.0-ra MTProto 1-ről.0

amint egy titkos csevegésben mindkét fél legalább a 73.réteget használja, csak az MTProto 2.0-t használja az összes kimenő üzenethez. Az első Beérkezett üzenetek egy része MTProto 1.0-t használhat, ha a titkos csevegés létrehozása során nem tárgyaltak kellően magas kezdő rétegről. Az MTProto 2.0-val titkosított első üzenet (vagy az első 73-as vagy újabb rétegű üzenet) beérkezése után az összes magasabb sorszámú üzenetet az MTProto 2.0-val is titkosítani kell.

amíg az aktuális réteg alacsonyabb, mint 73, minden félnek meg kell próbálnia visszafejteni a fogadott üzeneteket az MTProto 1.0-val, és ha ez nem sikeres (az msg_key nem egyezik), próbálja meg az MTProto 2.0-t. Amint megérkezik az első MTProto 2.0 titkosított üzenet (vagy a réteg 73-ra frissül), nem kell megpróbálnia az MTProto 1.0 visszafejtését a További üzenetek bármelyikéhez (kivéve, ha az ügyfél még mindig vár néhány hiányosság lezárására).

bejövő üzenet visszafejtése

a fenti lépéseket fordított sorrendben hajtjuk végre. Amikor titkosított üzenet érkezik, ellenőriznie kell, hogy az msg_key valójában megegyezik-e a visszafejtett üzenet SHA256 hashjának 128 középső bitjével, amelyet a megosztott kulcsból vett 32 bájt ír elő.Ha az üzenetréteg nagyobb, mint az ügyfél által támogatott, a felhasználót értesíteni kell arról, hogy az ügyfélverzió elavult, és a rendszer frissítésre kéri.

sorszámok

az összes üzenetet eredeti módon kell értelmezni, hogy megvédje a lehetséges manipulációkat. A titkos Csevegések egy speciális mechanizmust támogatnak a seq_no számlálók kiszolgálótól független kezelésére.

ezeknek a számlálóknak a megfelelő kezelését a következő cikk ismerteti: sorszámok titkos csevegésekben.

Felhívjuk figyelmét, hogy az ügyfélnek támogatnia kell a titkos Csevegések sorszámát, hogy kompatibilis legyen a hivatalos Telegram ügyfelekkel.

titkosított fájlok küldése

a titkos csevegésekhez küldött összes fájl egyszeri kulcsokkal van titkosítva, amelyek semmilyen módon nem kapcsolódnak a csevegés megosztott kulcsához. A titkosított fájl elküldése előtt feltételezzük, hogy a titkosított fájl címét a titkosított üzenet külső részéhez csatolják az üzenetek fájlparaméterével.sendEncryptedFile módszer, és hogy a kulcs a közvetlen visszafejtés kerül elküldésre a szervezetben az üzenet (a legfontosabb paraméter a konstruktorok decryptedMessageMediaPhoto, decryptedMessageMediaVideo és decryptedMessageMediaFile.

mielőtt egy fájlt titkos csevegésre küldenénk, 2 véletlenszerű 256 bites számot számítunk ki, amelyek AES kulcsként és inicializálási vektorként szolgálnak a fájl titkosításához. AES-256 titkosítás végtelen garble kiterjesztéssel (IGE) hasonló módon használják.

a kulcs ujjlenyomata a következőképpen kerül kiszámításra:

• digest = md5(kulcs + iv)
• ujjlenyomat = substr(digest, 0, 4) XOR substr (digest, 4, 4)

a fájl titkosított tartalma nagyjából ugyanúgy tárolódik a szerveren, mint a felhő csevegésekben lévő fájloké: darabonként a feltöltéshez szükséges hívások segítségével.saveFilePart.Egy későbbi hívás üzenetek.a sendencryptedfile hozzárendel egy azonosítót a tárolt fájlhoz, és elküldi a címet az üzenettel együtt. A címzett frissítést kap titkosítvaés a fájl paraméter fájlinformációkat tartalmaz.

a bejövő és kimenő titkosított fájlok továbbíthatók más titkos csevegésekhez az inputencryptedfile konstruktor segítségével, hogy elkerüljék ugyanazt a tartalmat a szerveren kétszer.

frissítési doboz használata

a titkos Csevegések meghatározott eszközökhöz (vagy inkább engedélyezési kulcsokhoz) vannak társítva, nem pedig felhasználókhoz. A hagyományos üzenetdoboz, amely pts-t használ az ügyfél állapotának leírására, nem megfelelő, mert hosszú távú üzenet tárolására és különböző eszközökről történő üzenet-hozzáférésre tervezték.

egy további ideiglenes üzenetsor kerül bevezetésre a probléma megoldására. Amikor egy titkos csevegésből származó üzenetre vonatkozó frissítést küldenek, a qts Új értéke kerül elküldésre, amely segít rekonstruálni a különbséget, ha a kapcsolat hosszú szünetet tartott, vagy egy frissítés elvesztése esetén.

az események számának növekedésével a qts értéke minden új eseménynél 1-gyel növekszik. A kezdeti érték nem lehet (és nem is lesz) egyenlő 0-val.

azt a tényt, hogy az ideiglenes várólista eseményeit az ügyfél fogadta és tárolta, kifejezetten az üzenetek hívása nyugtázza.receivedQueue módszer vagy implicit módon egy hívást a frissítéseket.getdifferencia (a QTS értéke elhaladt, nem a végső állapot). Az ügyfél által kézbesített összes üzenet, valamint a 7 napnál régebbi üzenetek törölhetők (és lesznek) a szerverről.

az engedélyezés megszüntetése után a megfelelő eszköz eseménysora erőszakkal törlődik, és a qts értéke irreleváns lesz.

frissítés új rétegekre

az ügyfélnek mindig a titkos csevegés másik oldalán kell tárolnia azt a maximális réteget, amelyről ismert, hogy az ügyfél támogatja. A titkos csevegés első létrehozásakor ezt az értéket 46-ra kell inicializálni. Ezt a távoli rétegértéket mindig azonnal frissíteni kell, miután megkapta a felső réteg információit tartalmazó csomagot, azaz.:

• bármely titkos csevegőüzenet, amely a layer_no-t tartalmazza a decryptedMessageLayer réteggel>=46, vagy
• egy decryptedMessageActionNotifyLayer szolgáltatási üzenet, úgy csomagolva, mintha az elavult 8.réteg decryptedMessageService konstruktora lenne (konstruktor decryptedMessageService#aa48327d).

A távoli Ügyfél értesítése A helyi rétegről

annak érdekében, hogy értesítse a távoli ügyfelet a helyi rétegről, az ügyfélnek decryptedMessageActionNotifyLayer típusú üzenetet kell küldenie. Ezt az értesítést egy megfelelő réteg konstruktorába kell csomagolni.

két eset van, amikor az ügyfélnek értesítenie kell a távoli ügyfelet a helyi rétegéről:

1. amint új titkos csevegés jött létre, közvetlenül a titkos kulcs sikeres cseréje után.
2. közvetlenül a helyi kliens frissítése után, hogy támogassa az új titkos csevegési réteget. Ebben az esetben értesítéseket kell küldeni az összes jelenleg létező titkos csevegésre. Vegye figyelembe, hogy erre csak akkor van szükség, ha olyan új rétegekre frissül, amelyek a titkos Csevegések megvalósításában változásokat tartalmaznak (pl. ezt nem kell megtennie, ha az ügyfél a 46.rétegről a 47. rétegre frissül).