PGP-ellenőrzés piactéri linkekhez és eladói üzenetekhez

Egy aláírt közleményen szereplő PGP-aláírás egyetlen, szűken értelmezett dolgot bizonyít: annak, aki közzétette az üzenetet, hozzáférése volt ahhoz a privát kulcshoz, amely az adott piachoz már nálad lévő nyilvános kulcshoz tartozik. Azt nem bizonyítja, hogy a piac becsületes, hogy jelenleg elérhető, vagy hogy a rendelésed meg fog érkezni. Csupán a kulcs birtokosának folytonosságát igazolja attól a pillanattól kezdve, amikor megkaptad a nyilvános kulcsot, egészen addig, amíg az új linket vagy a karbantartási frissítést aláírták.

Három dolog, amit az aláírás valóban igazol

Kulcsfolytonosság. Ha a régi onion egy új oniont tartalmazó üzenetet írt alá, és az aláírás egy hetekkel korábban elmentett nyilvános kulccsal ellenőrizhető, akkor az üzemeltető nem a semmiből bukkant fel. Egy klónoldal üzemeltetője nem rendelkezik ezzel a privát kulccsal, így az aláírt közleménye akkor is megbukik az ellenőrzésen, ha az oldala pixelpontosan ugyanúgy néz ki.

Üzenetintegritás. Az aláírt szöveg nem módosult, mióta elhagyta az üzemeltetőt. Aki közted és a közlemény között helyezkedik el, az nem cserélhet be másik onioncímet, másik fizetési címet vagy másik karbantartási ütemtervet anélkül, hogy az aláírás érvényét ne veszítené. A matematika a szöveget a kulcshoz köti.

A szándék időzítése. A rotáció pillanatában létrehozott aláírás azt mutatja, hogy ugyanaz a kulcsbirtokos szándékosan hagyta jóvá az új címet. Azt nem mutatja, hogy az üzemeltető biztonságos. Azt mutatja, hogy ugyanazzal az azonosító hitelesítő adattal rendelkezik, mint korábban, és ez az egyetlen stabil rögzítési pont, amikor minden más felület változik.

1. A kulcsbirtokos megírja a frissítéstAz üzemeltető egyszerű szövegben közli az új oniont és az esetleges karbantartási időszakot
2. Az aláírás létrejönA szöveget a piac hosszú távú PGP-kulcsával írják alá
3. Az üzenetet közzéteszikAz aláírt szöveg és az aláírás együtt terjed tükrökön vagy beillesztési csatornákon keresztül
4. Te ellenőrzölA mentett nyilvános kulcsod ellenőrzi az aláírást a pontosan beérkezett szöveggel szemben
5. A rotált link elfogadvaHa az ellenőrzés sikeres, az új onion örökli azt a bizalmat, amelyet már korábban ebbe a kulcsba helyeztél

Gondolj a PGP-kulcsra úgy, mint egy pecsétre, amelyet a gyakorlatban nem lehet hamisítani: bárki kinyomtathat egy hivatalosnak tűnő oldalt, de a pecsétet csak egyetlen fél nyomhatja a papírra. Az érvényes aláírás a rányomott pecsét. Azt mondja el, hogy ugyanaz a kéz, amelyik a régi oldalt megjelölte, az új oldalt is megjelölte — nem azt, hogy a kéz jóindulatú, józan vagy fizetőképes.

Egy aláírt bejelentés és egy klónozott szövegfal első pillantásra gyakran egyformának tűnik: ugyanaz a piactérnév, ugyanaz a megfogalmazás, ugyanaz az új tükrökből álló lista. Ami megváltozik, az az, amit az aláírás ténylegesen lefed — a kulcs, amely az üzenetet hitelesíti, és a benne szereplő, üzemeltető által ellenőrzött adatok. Amikor az üzemeltető aláír egy rotációs értesítést, az aláírás az új címet ugyanahhoz a kulcshoz köti, amely a korábbi bejelentéseket is aláírta. Egy klón le tudja másolni a formázást, és akár a régi szöveget is újra fel tudja használni, de nem tud friss aláírást előállítani az üzemeltető privát kulcsával. Ez az első konkrét különbség: az aláírt frissítés érvényes, aktuális bizonyítékot hoz létre, míg a klónnak vagy nincs aláírása, vagy olyat hordoz, amely nem egyezik az olvasó kulcstartójában már megbízhatóként megjelölt kulccsal.@@H3 A két látható elmozdulás: kulcsfolytonosság és kötési minőség@@GLOSSARY Kulcsfolytonosság :: hogy az új bejelentés aláíró kulcsa ugyanaz-e, amelyet az üzemeltető az előző hitelesített frissítésnél használt || Kötési minőség :: hogy az aláírás valóban lefedi-e az új tükörcímet és a szavakat, vagy csupán dekorációként áll mellettük || Megbízható kulcstartó :: a már hitelesített üzemeltetői kulcsok helyi készlete, amelyet az olvasó a rotáció előtt elfogadott@@COMPARE Mi változik egy valódi frissítés és egy klón között | Aláírt üzemeltetői frissítés | Adathalász klón ;; Aláírás-ellenőrzés :: sikeres a korábban megbízhatónak jelölt üzemeltetői kulccsal szemben :: sikertelen, vagy egy új, hitelesítetlen kulcsra mutat ;; Tükörcím az üzenetben :: az aláíráshoz kötött; egy sor megváltoztatása megtöri a bizonyítékot :: szabadon módosítható, mert nem fedi le működő aláírás ;; Sürgető nyelvezet :: általában semleges és tárgyszerű, még akkor is, ha a felhasználókat költözésre kérik :: gyakran pánikra, lejáratra vagy „végső figyelmeztetésre” épít, hogy gyors kattintást érjen el ;; Hatás az olvasó kulcstartójára :: megerősíti ugyanannak az üzemeltetőnek a folytonosságát :: a bizalmat egy friss, ki nem érdemelt kulccsal próbálja helyettesíteni @@P Ez a második elmozdulás az oka annak, hogy egy aláíratlan vagy rosszul kulcsolt frissítés korai figyelmeztető jelként olvasandó, nem pedig apró formázási hibaként. Ha egy üzemeltetőnek fegyelmezett aláírási szokásai vannak, a komoly rotációs értesítések alapértelmezetten aláírottak — ez az üzenet része, nem pedig opcionális kiegészítő. Egy klónüzemeltető jellemzően a tükrözött oldal szövegét tudja ellenőrizni, az aláírási láncot azonban nem. Így a vörös zászló már azelőtt megjelenik, hogy a felhasználó bármire kattintana: a régi kulcs itt semmit sem mond, vagy az ellenőrzés azonnal meghiúsul.@@P Gondolj rá úgy, mint egy bankfiókra, amely új címre költözik. A valódi bank az értesítést olyan levélpapíron küldi, amely megegyezik a korábbi levélpapírral, és ugyanazt a pecsétet viseli, amelyet már ellenőriztél. Egy hamis értesítés ugyanazt a logót és ugyanazt a megfogalmazást használhatja, de a pecsét hiányzik, elmosódott, vagy más bélyegzővel készült. A szöveg nem változott — a mögötte álló jogosultság igen. Ez a szakadék a másolt szavak és a bizonyítatlan jogosultság között pontosan az, amit a PGP-hitelesítés elválaszt egymástól.@@COMPARE Amit az olvasó összehasonlít, mielőtt megbízna a linkben | Régi hitelesítési állapot | Új frissítés ;; Aláíró kulcs :: az üzemeltetői kulcs már megbízhatóként van megjelölve :: ugyanaz a megbízható kulcs írja alá az új értesítést ;; Üzenettartalom :: korábbi rotációs szavak és tükörlista :: új tükörlista, amelyet az aláírás köt ;; Klón hibamód :: nem értelmezhető az átvételi kísérlet előtt :: a klón aláírás nélkül vagy ismeretlen kulccsal aláírva érkezik ;; Gyakorlati vörös zászló :: az ismerős kulcs aláírása hiányzik :: az olvasó megtört bizonyítékot lát, mielőtt az új onionra kattintana @@P A gyakorlati következmény az, hogy a klónoldal gyakran azt próbálja elhitetni, hogy a hitelesítés felesleges. Azt mondja az olvasónak, hogy „ez az új aláírt bejegyzés”, miközben nem mutat aláírást, vagy hogy „a kulcs biztonsági okból megváltozott”, miközben nem ad olyan magyarázatot, amelyet egy üzemeltető általában megadna. Egy aláírt frissítés ezzel szemben a kulcsot a link iránti bizalom okaként kezeli — nem pedig kellemetlenségként, amely mellett el kell görgetni.

A vendorüzenetek két szerkezetileg eltérő esetre bonthatók. Ha egy jegyzet a nyilvános kulcsodra van titkosítva, csak a hozzá tartozó privát kulcs birtokosa tudja elolvasni. Ez azt jelenti, hogy a vendor egy konkrét vevői identitást szólított meg, nem pedig szórt üzenetet küldött. Az is következik belőle, hogy az üzenet későbbi idézése kisebb súllyal bír, hacsak az olvasó nem tudja ugyanazzal a kulccsal önállóan megnyitni ugyanazt a titkosított szöveget. A titkosítás iránya többet számít az üzenet tartalmánál: megmutatja, kit akart elérni a másik fél, és mely kulcsanyagban bízott abban a pillanatban.

Az a vendor, aki ugyanazt a kulcsot használta megrendeléseken, vitákon és címváltozásokon keresztül, folytonossági szálat hoz létre. Ha ugyanaz a kulcs ír alá egy üzenetet, amely szerint „használd ezt az új kulcsot”, az átállás egy olyan dologhoz van rögzítve, amit már ellenőriztél. Ha viszont a vendor vita vagy sikertelen kézbesítés után egyszerűen új kulccsal kezd aláírni, semmi sem köti az új kulcsot a korábbi identitáshoz. Egy támadó, aki a fiókot irányítja, pontosan ezt tehetné.

A különbség viták esetén válik élessé. Az a vevő, aki be tudja mutatni, hogy egy titkosított rendelési jegyzet a privát kulcsával nyílik meg, olyasmivel rendelkezik, amit a vendor annak a konkrét címzettnek készített. Ha a vendor később másik fiókra vagy kulcsra hivatkozik, a bizonyíték nem követi át a szakadáson. Az érték a folytonosságban van, nem magában a titkosításban.

A legtöbb ellenőrzési kudarcot nem hibás szoftver vagy egy elgépelt karakter okozza. Abból fakad, hogy az aláírt bejelentést állandóan érvényes engedélyként kezeljük, pedig valójában egyszeri nyugta, amely egyetlen konkrét pillanathoz kötődik. Jó hasonlat erre a szállodai kulcskártya: a kártya igazolja, hogy a recepció egy adott szobához és dátumra állította ki. Azt nem bizonyítja, hogy az illető, aki holnap a kártyát mutatja, még mindig ott dolgozik, és azt sem, hogy az ajtó mögötti szobát azóta nem számozták át. Az aláírás azt mutatja, ki adta ki az üzenetet, és hogy annak tartalma nem változott. Semmit nem mond arról, mit dönt az üzemeltető a következő héten közzétenni, és nem teszi a linket biztonságos könyvjelzővé.

A hasonlat akkor kezd sántítani, amikor a tükörcím-forgatás belép a képbe. A szállodai kulcskártyát minden ott-tartózkodáskor fizikailag újra kiállítják; egy aláírt piactéri link viszont másolható, továbbítható, és hónapokkal azután is újrahasználható, hogy az üzemeltető lecserélte az infrastruktúrát. Ugyanazt az aláírt linket hónapokig használni olyan, mint bejelentkezni egy szállodába, távozni, majd egy évvel később ugyanazzal a kártyával próbálkozni, mert a műanyag még mindig hivatalosnak tűnik. Az aláírás arra volt érvényes, ami akkor volt. Nem szerződés arra, hogy ugyanaz az onion-cím marad örökre az egyetlen bejárat.

Egy másik gyakori csapda, amikor minden kulcsot felcserélhetőnek tekintünk egy tükörváltás során. A felhasználó új linkbejelentést kap, aláírást lát, és azt feltételezi, hogy a kulcs a piachoz tartozik, csak mert az üzenet úgy néz ki, mint egy piactéri frissítés. Ha nem ugyanaz a PGP-kulcs írta alá, mint ami az előző frissítést, az maga a jelzés. A megváltozott kulcs nem figyelmen kívül hagyható kellemetlenség; ez a különbség egy új kulcs és egy új üzemeltető között.

Zavarosabb változat fordul elő az eladó-specifikus üzeneteknél. Ha egy eladó titkosított üzenetet küld, amely a piactéri leállást vagy tükörcserét említi, a felhasználó gondolatban összemoshatja az eladói kulcsot a piactéri kulccsal. Az eladó a saját rendeléseiről vagy a saját elérhetőségéről szóló üzenetet írt alá. A piactéri üzemeltető által aláírt piactéri tükör egészen más identitás. Ha szem elől tévesztjük, melyik kulcsnak kellene melyik típusú bejelentést aláírnia, egy rutinszerű eladói frissítés hamis bizonyossággá válhat, hogy maga a piactér erősített meg egy linket.

Az érvényes aláírás a kockázatot a „valóban az igazi üzemeltető ez?” kérdésről arra szűkíti, hogy „mi változott azóta, hogy a kulcsban utoljára megbíztunk?”. Ez a második kérdés a napi használatban fontosabb. A piacterek lecserélhetnek egy aláíró alkulcsot, visszavonhatnak egy lejárt bejelentési kulcsot, vagy megváltoztathatják a preferált kapcsolattartási ujjlenyomatot úgy, hogy közben ugyanaz a csapat irányítja őket. A jó aláírást csak az adott üzenet folytonosságának bizonyítékaként kezeld — ne pedig általános garanciaként minden tükörre, eladóra vagy a piachoz kapcsolódó támogatási fiókra.

Egyetlen jó aláírás egyetlen üzenetet igazol. Nem kezeskedik a következő linkért, a következő álnévért vagy a következő személyért, aki idézi.

Ha az aláírás rendben van, a gyakorlati következő lépés attól függ, hogy az üzenet valójában mire kér. Egy új tükörről szóló aláírt bejelentés más, mint egy aláírt eladói üzenet a rendelésedről.

1. Aláírás-ellenőrzés új piaci linknélNyisd meg az aláírt bejelentést, és jegyezd fel, melyik ujjlenyomat hozta létre. Ha egyezik egy olyan kulccsal, amellyel már rendelkezel egy korábbi ellenőrzött munkamenetből, hasonlítsd össze az új címet a piac által korábban használt formátummal. Ha mindkettő egyezik, a link használható böngészésre.
2. Az aláírás érvényes, de az ujjlenyomat új vagy csak alkulcsNe adj le azonnal rendelést. Az üzenet még lehet jogszerű — lejárati csere vagy alkulcs-változás —, de ezt másik csatorna nélkül nem tudod megkülönböztetni egy átvételtől. Várj egy második aláírt megerősítésre egy másik útvonalról, például egy már megbízható eladótól vagy egy külön mentett kapcsolattól.
3. Az aláírás hibás vagy az üzenet aláíratlanÁllj meg, és kezelj minden benne lévő utasítást szemétként. Linkek, pénztárca-frissítések, „kötelező jelszó-visszaállítás” felszólítások — egyiket se kövesd. Egy klón lemásolhatja egy valódi frissítés szövegét, miközben az aláíráson elbukik.
4. Az eladói üzenet visszafejthető, és azt írja, hogy a rendelésed megerősítésre szorulA titkosítás csak azt bizonyítja, hogy az üzenet a nyilvános kulcsodra készült. Nem bizonyítja, hogy a feladó az eladó. Hasonlítsd össze az eladó aláírókulcs-történetét. Ha az eladó nem írja alá az üzeneteit, kérd meg, hogy a rendelés részleteit kösse az ismert PGP-identitásához, mielőtt bármit elküldenél.

Gyakori hamis magabiztosság abból fakad, hogy az „aláírás érvényes” állapotot úgy kezelik, mintha „most már minden biztonságos” lenne. Egy aláírt üzenet akkor is átadhat olyan linket, amely lefoglalt vagy klónozott felületre mutat, ha a kulcsot korábban csendben lecserélték. Ezért fontosabb a folytonosság, mint egyetlen egyezés.