Packet inspection vs. šifrování

PanSauron

Packet inspection vs. šifrování
« kdy: 27. 01. 2017, 12:04:29 »
Mam takovy koncepcni dotaz, jak moc asi predevsim https muze stizit zivot adminum?

Modelova situace:
Kód: [Vybrat]
|internet| ---- |fw|-----|firemni pc|
                  |
                |IDS|

Uzivatel Pepa vleze na stranky kde je nejaky opravdu zly kod v javascriptu (vidime max. url), cele to vsak jede pres https, takze nemuzeme zkontrolovat napr. hloupe "signaturu" nebo neco co by eventualne skodlivy kod identifikovalo/prozradilo. Nejsem si jisty, ze by antivirus mohl sahat a kontrolovat primo javascript (teoreticky ano v praxi to muze by ponekud obskurni - mozna do toho jenom tolik nevidim, jde mi o to, ze by to muselo ten js pustit, vyhodnotit a to muze spomalovat nacitani stranky. Proto trochu pochybuji o efektivite takoveho reseni.). Nicmene, enduser stanice to muze "kontrolovat", coz dle meho muze byt do jiste miry pozde.

IDS mi na Layer 7 asi nesahne a pokud ano musi videt na co saha. Reseni jako mela MS ISA FW, kdy to delalo MITM, aby to mohlo skenovat antivirem obsah paketu mi neprijde uplne koser, ale je to relativne koncepcne funkcni.

Chapu, ze tedka asi mate pocit, ze porovnavam IDS s AV, ne neni tomu tak. To o co mi jde, je mysleno ponekud jinak, kdyz mi zacne totiz Pepa nevedomky zacit posilat pakety na podivnaurl.com chtel bych byt schopny sparovat si, jestli nekde v predchozich paketech prave podivnaurl.com byla a mit tak moznost napr. zdrojovou stranku "zariznout". Nejde mi o to vykonavat javascript, jde mi o identifikaci dat z L7 a "zpetne vazby/akce", ktere eventualne daji na L4 a niz, resp. kdyz zjistim podivny odchozi traffic, tak abych ho eventualne mohl zariznout pri dalsim prichozim (uzivatel Pepa poslal odkaz na stranku Frantovi). Takze kolem a kolem, sifrovat je treba, ale prinasi to takoveto vyzvy. Obecne, jak moc sifrovani stizi zivot IDSkum?

Diky za nazory a postrehy, eventualne odkazy a literaturu atd.
« Poslední změna: 30. 01. 2017, 08:50:29 od Petr Krčmář »


NN

Re:Packet inspection vs Encryption
« Odpověď #1 kdy: 27. 01. 2017, 15:31:39 »
Bud host intrusion protection, teda IDS/IPS na endpointe, alebo SSL decryption na network IDS/IPS.

Jenda

Re:Packet inspection vs Encryption
« Odpověď #2 kdy: 27. 01. 2017, 16:45:02 »
alebo SSL decryption na network IDS/IPS.
Takže mu musíš nainstalovat vlastní CA a nejspíš vypnout pinning a další opatření pro detekci MITM. A pokud si ta IDS nedá fakt dobrý pozor aby tyhle věci dodržovala a reportovala klientovi, tak efektivně bezpečnost snížíš.

resp. kdyz zjistim podivny odchozi traffic, tak abych ho eventualne mohl zariznout pri dalsim prichozim (uzivatel Pepa poslal odkaz na stranku Frantovi)
Asi ten příklad budeš muset trochu rozvést, protože si moc nedokážu představit, o co ti jde. Proti cílenému útoku to asi nepomůže a proti necílenému nevím, nebylo by lepší browser sandboxovat? A pokud uvažujeme díru v browseru spouštěnou přes JS - myslíš, že tvoje IDS bude mít signatury dřív než výrobce prohlížeče vydá aktualizaci?

Re:Packet inspection vs Encryption
« Odpověď #3 kdy: 27. 01. 2017, 19:34:55 »
jak moc asi predevsim https muze stizit zivot adminum?
Opravdu si myslíte, že se ten škodlivý kód může dostat do počítače jenom přes HTTPS? Nemůže se tam dostat i kterýmkoli jiným protokolem, přes flash disk, nemůže ho tam uživatel prostě vytvořit?

Podle mne je neudržitelné snažit se kontrolovat jeden druh komunikace. Spíš dává smysl oddělovat aplikace a povolit jim jenom to, co mají dělat. Jako je to na mobilních platformách (iOS a Android). Antivir teoreticky JavaScript kontrolovat může, ale pokud už je známá nějaká díra v prohlížeči, je lepší opravit ten prohlížeč než se pokusit antivirem odhalit kód, který tu chybu zneužívá.

PanSauron

Re:Packet inspection vs. šifrování
« Odpověď #4 kdy: 30. 01. 2017, 14:16:28 »
@Jendo, Filipe,

dekuju za komenty. To co se snazim vyresit neni jenom o HTTPS a priklad s Javascriptem je predevsim modelovy. Resim spise tu problematiku obecne, tzn. cim vice bude sifrovane komunikace, tim hure se bude dat detekovat na siti resp. identifikovat zname druhy utoku resp. spise provozu. Jak jsem nastinil reseni jako ma napr. MS ISA FW (uz ho snad ani nedelaji), kde se podvrhavaly certifikaty, desifrovalo se spojeni a provadela se antivirova kontrola. Vim, ze to neni spravne reseni, proto se snazim jaksi najit neco schudneho a zaroven se uplne nechci spolehat jenom na AV na koncovem zarizeni (viz. napr: http://www.theregister.co.uk/2017/01/27/gag_free_ex_mozilla_dev_joins_antivirus_roasting_chorus_its_poison/).

Nechci tady vyvolat flame o AV. Spis se snazim najit nejakou jinou metodu jak by se daly utoky identifikovat a "zariznout". Nechci si hrat na antivirus to je hloupost. Chci spise zjistit jak nejlepe monitorovat "bezne chovani" na siti a pokud napr. nejaky skodlivy kod zacne z moji site odesilat data nebo se sirit, tak tuto komunikaci "zariznout". Jako priklad jsem uvedl "zavirovane stranky" a jak se Pepa nevedomky stane obeti utoku, ale protoze na strankach je roztomily obrazek kocicky, posle to i Frantovi. Franta by uz mel ale mit stranky znepristupnene protoze IDS/IPS uz bude vedet, ze se napr. z Pepova prohlizece zacaly odesilat nejaky fragmenty dat na podivnou IP/url. Nejedna se mi o to najit konkretni reseni na konkretni problem, ale urcitou metodiku/doporuceni jak se v budoucnu se sifrovanim potykat na popsanem problemu. Chapu, ze se daji posilat data v ruznem "formatu" pres ruzne protokoly, rekneme, ze se snazim co nejlepe identifikovat "signaturu" komunikace, podobne jako AV ma napr. signaturu pro znamy skodlivy kod (ano metod je na to vice).

Vysledek by mel byt ten, ze pokud napr. se nakazi jeden pocitac, stihne nakazit maximalne dalsi tri v siti, ale pote uz bude znama signatura komunikace a sitova pravidla jednoduse pakety zahodi nebo s nimi provedou neco jineho, co neohrozi ostatni pocitace v siti. Muzeme predpokladat dva druhy site "domaci" kde bude jiste hodne "falesnich poplachu", ale to co me zajima je predevsim "striktni korporatni" rekneme, kde se da definovat mnohem lepe co je "zadouci" a "nezadouci" druh komunikace.

Snad jsem to upresnil dostatecne, dekuji za dalsi komenty a podnety.


Michal Kovačič

Re:Packet inspection vs Encryption
« Odpověď #5 kdy: 30. 01. 2017, 16:10:07 »
jak moc asi predevsim https muze stizit zivot adminum?
Opravdu si myslíte, že se ten škodlivý kód může dostat do počítače jenom přes HTTPS? Nemůže se tam dostat i kterýmkoli jiným protokolem, přes flash disk, nemůže ho tam uživatel prostě vytvořit?

Podle mne je neudržitelné snažit se kontrolovat jeden druh komunikace. Spíš dává smysl oddělovat aplikace a povolit jim jenom to, co mají dělat. Jako je to na mobilních platformách (iOS a Android). Antivir teoreticky JavaScript kontrolovat může, ale pokud už je známá nějaká díra v prohlížeči, je lepší opravit ten prohlížeč než se pokusit antivirem odhalit kód, který tu chybu zneužívá.

Hmm...

O tomhle jsem docela přemýšlel - a teoreticky musím souhlasit, prakticky určitě ne :-)

A/ vektor šíření (jak se cokoli špatného dostane do počítače) je dnes prakticky 100% síť. Libovolný protokol - samozřejmě. Diskety, CD, DVD - jsou nejspíše historií. Flashky nejrůznějších druhů stále mohou přenést něco špatného, ale do dalšího výzkumu bych tuhle hrozbu zanedbal jako minimální.

B/ Přístup opravit chybný SW je ideální. Nebo vůbec jej psát správně a bezpečně. Tolik teorie - praxi znáte určitě lépe něž já. Opravit cokoli stojí čas a peníze - kdo to zaplatí a kdy se to udělá (viz Android...). A pokud je zde oprava chyby, jak zajistit aby se aplikovala - ideálně všude. Myslím, že i teď je na rootu článek o chybě, která je vážná, opravena někdy v hluboké historii (z hlediska IT) a stále je hodně zařízení, které opravu ignorují...

Osobně jsem přesvědčen, že musíme najít "jeden" bod, kde se vše sbíhá a rozmyslet si, jak ten změnit aby bylo IT bezpečnější. Z čistě teoretického hlediska jsme jeden moment promeškali (IPv6), ale možná příště. Jo, a v IT je strašná spousta lidí, co tomu rozumí nekonečně lépe než já - možná někdo dostane nápad :-) Můj funguje v teorii - ale tam funguje všelicos...

Jenda

Re:Packet inspection vs Encryption
« Odpověď #6 kdy: 30. 01. 2017, 18:33:26 »
A pokud je zde oprava chyby, jak zajistit aby se aplikovala - ideálně všude.
Tazatel je administrátor té sítě - tak snad má nějak centrálně vyřešené updaty. Kdyby ne, tak by měl v první řadě vyřešit updaty a pak až rejpat do nějaké IPS.

Osobně jsem přesvědčen, že musíme najít "jeden" bod, kde se vše sbíhá a rozmyslet si, jak ten změnit aby bylo IT bezpečnější. Z čistě teoretického hlediska jsme jeden moment promeškali (IPv6)
Nevidím, co s tím má společného síťový protokol.

j

Re:Packet inspection vs Encryption
« Odpověď #7 kdy: 30. 01. 2017, 18:55:39 »
...
Nevidím, co s tím má společného síťový protokol.
Mozna to, ze jeho povinou soucasti bejvalo i sifrovani ... a tudiz by se nemuselo resit jak zasifrovat ten ci onen protokol, protoze by se to sifrovalo rovnou vsechno o vrstvu niz.

Unknown

Re:Packet inspection vs Encryption
« Odpověď #8 kdy: 30. 01. 2017, 20:09:15 »
A pokud je zde oprava chyby, jak zajistit aby se aplikovala - ideálně všude.
Tazatel je administrátor té sítě - tak snad má nějak centrálně vyřešené updaty. Kdyby ne, tak by měl v první řadě vyřešit updaty a pak až rejpat do nějaké IPS.

Osobně jsem přesvědčen, že musíme najít "jeden" bod, kde se vše sbíhá a rozmyslet si, jak ten změnit aby bylo IT bezpečnější. Z čistě teoretického hlediska jsme jeden moment promeškali (IPv6)
Nevidím, co s tím má společného síťový protokol.

Nejspis mysli ze IPv6 krome spousty "vylepseni" mela implementovat jeste taky neco z bezpecnosti ;-)

Re:Packet inspection vs. šifrování
« Odpověď #9 kdy: 30. 01. 2017, 21:10:02 »
Resim spise tu problematiku obecne, tzn. cim vice bude sifrovane komunikace, tim hure se bude dat detekovat na siti resp. identifikovat zname druhy utoku resp. spise provozu.



Chci spise zjistit jak nejlepe monitorovat "bezne chovani" na siti a pokud napr. nejaky skodlivy kod zacne z moji site odesilat data nebo se sirit, tak tuto komunikaci "zariznout". Jako priklad jsem uvedl "zavirovane stranky" a jak se Pepa nevedomky stane obeti utoku, ale protoze na strankach je roztomily obrazek kocicky, posle to i Frantovi. Franta by uz mel ale mit stranky znepristupnene protoze IDS/IPS uz bude vedet, ze se napr. z Pepova prohlizece zacaly odesilat nejaky fragmenty dat na podivnou IP/url.



Vysledek by mel byt ten, ze pokud napr. se nakazi jeden pocitac, stihne nakazit maximalne dalsi tri v siti, ale pote uz bude znama signatura komunikace a sitova pravidla jednoduse pakety zahodi nebo s nimi provedou neco jineho, co neohrozi ostatni pocitace v siti.
To, co popisujete, neřeší podstatu problému, ale původní problém ignoruje a pak se ho snaží někde cestou dohonit. Nejste v tom sám, ve skutečnosti v tom s vámi jede velká část bezpečnostního IT průmyslu. A i tam to má jakousi historickou logiku, protože když je problém v bezpečnostním modelu proprietárních Windows, těžko mohou externisté ten problém opravit a jediné, co jim opravdu zbývá, je pokusit se ten problém dohonit někde venku. Předpokládám ale, že vy se ptáte na nějaké řešení v dlouhodobějším horizontu, které bude použitelné i ve světě, kde bude kladen velký důraz na ochranu soukromí, tudíž i na end-to-end šifrování komunikace.

„Identifikovat známé druhy útoků“, „detekovat známý provoz“, „stihne nakazit tři počítače v síti“ – to přece nechcete, to jsou jenom špatné nástroje. To, co popisujete, je jako kdybyste svůj majetek „chránil“ tak, že doma nebudete mít žádný dveře natož zámky, všechno bude volně přístupné, lidi budou chodit dovnitř a ven – a vy budete neustále zdokonalovat techniky, jak venku na náměstí poznávat, který člověk nese co vašeho, jak odlišit „běžné chodce“ o těch, kteří od vás právě odcházejí s lupem.

Jako příklad jste uváděl webový prohlížeč. Tam útoky vypadají tak, že existuje nějaká (alespoň pro někoho) známá chyba, třeba buffer overflow při zpracování obrázku. Abyste ten útok dokázal zachytit na síti, musíte jednak tu chybu znát, a pak se musíte pokusit z probíhající komunikace uhodnout, že se někdo pokouší tu chybu zneužít. Což může být dost pracné, navíc prohlížeč může komunikovat s mnoha servery a dokonce přes víc sítí (může mít jeden soubor nakešovaný z připojení přes WiFi v domácí síti a druhý si stáhne přes kabel v práci). Navíc celé to pracné hádání je dost zbytečné, protože když už je ta chyba známá, je nejsnazší jí opravit (nebo alespoň nějak zalátat) právě v tom prohlížeči. A skutečné řešení pak spočívá v tom, že i jednotlivé komponenty prohlížeče od sebe musí být oddělené a musí mezi nimi fungovat bezpečnostní bariéry. Webový prohlížeč je dnes už vlastně takový druhý operační systém, a stejně jako v operačním systému máte alespoň oddělené uživatele a lépe i procesy a ne každý proces může dělat cokoli, stejně to bude muset být i ve webovém prohlížeči a v dalších komplexnějších programech. Komponenta pro vykreslování obrázků nepotřebuje komunikovat přes internet, a je neudržitelné, aby chyba v takové komponentě umožnila spustit kód, který může v prohlížeči udělat cokoli (jakoby běžel v prohlížeči s pomyslnými rootovskými právy).

Na úrovni počítačové sítě pak půjde spíš o ochranu vlastních zařízení před útoky zvenčí (tj. aby nebyla zařízení napadnutelná známými chybami) a pak hlavně asi dohledatelnost, tj. abyste byl schopen určit, kdo je za které zařízení zodpovědný.

Franta <xkucf03/>

Re:Packet inspection vs. šifrování
« Odpověď #10 kdy: 30. 01. 2017, 21:49:48 »
Mam takovy koncepcni dotaz, jak moc asi predevsim https muze stizit zivot adminum?

Modelova situace:
Kód: [Vybrat]
|internet| ---- |fw|-----|firemni pc|
                  |
                |IDS|

Uzivatel Pepa vleze na stranky kde je nejaky opravdu zly kod v javascriptu (vidime max. url), cele to vsak jede pres https, takze nemuzeme zkontrolovat napr. hloupe "signaturu" nebo neco co by eventualne skodlivy kod identifikovalo/prozradilo. Nejsem si jisty, ze by antivirus mohl sahat a kontrolovat primo javascript (teoreticky ano v praxi to muze by ponekud obskurni - mozna do toho jenom tolik nevidim, jde mi o to, ze by to muselo ten js pustit, vyhodnotit a to muze spomalovat nacitani stranky. Proto trochu pochybuji o efektivite takoveho reseni.). Nicmene, enduser stanice to muze "kontrolovat", coz dle meho muze byt do jiste miry pozde.

IDS mi na Layer 7 asi nesahne a pokud ano musi videt na co saha. Reseni jako mela MS ISA FW, kdy to delalo MITM, aby to mohlo skenovat antivirem obsah paketu mi neprijde uplne koser, ale je to relativne koncepcne funkcni.

Chapu, ze tedka asi mate pocit, ze porovnavam IDS s AV, ne neni tomu tak. To o co mi jde, je mysleno ponekud jinak, kdyz mi zacne totiz Pepa nevedomky zacit posilat pakety na podivnaurl.com chtel bych byt schopny sparovat si, jestli nekde v predchozich paketech prave podivnaurl.com byla a mit tak moznost napr. zdrojovou stranku "zariznout". Nejde mi o to vykonavat javascript, jde mi o identifikaci dat z L7 a "zpetne vazby/akce", ktere eventualne daji na L4 a niz, resp. kdyz zjistim podivny odchozi traffic, tak abych ho eventualne mohl zariznout pri dalsim prichozim (uzivatel Pepa poslal odkaz na stranku Frantovi). Takze kolem a kolem, sifrovat je treba, ale prinasi to takoveto vyzvy. Obecne, jak moc sifrovani stizi zivot IDSkum?

Diky za nazory a postrehy, eventualne odkazy a literaturu atd.

Dej uživateli nástroj, aby mu prohlížeč běžel v „sandboxu“ a nemohl ohrozit jeho data a ostatní aplikace běžící na jeho počítači. Zajisti, aby proces prohlížeče mohl přistupovat jen k serverům na internetu a nemohl se připojovat k ničemu na LAN (na intranet používejte prohlížeč běžící v jiném kontextu, který zase nemůže na internet), dále aby nemohl přistupovat k poště, soukromým klíčům a dalším citlivým souborům. Prohlížeči stačí přístup do adresáře s jeho profilem a jedné složce pro donwload/upload (tu můžeš nechat hlídat antivirem).

Dbej o aktualizace softwaru a používej bezpečný operační systém. A v neposlední řadě investuj něco do vzdělávání uživatelů.

Re:Packet inspection vs. šifrování
« Odpověď #11 kdy: 30. 01. 2017, 22:09:10 »
Dej uživateli nástroj, aby mu prohlížeč běžel v „sandboxu“ a nemohl ohrozit jeho data a ostatní aplikace běžící na jeho počítači. Zajisti, aby proces prohlížeče mohl přistupovat jen k serverům na internetu a nemohl se připojovat k ničemu na LAN
xkcd: Authorization

Michal Kovačič

Re:Packet inspection vs. šifrování
« Odpověď #12 kdy: 31. 01. 2017, 10:12:23 »
To, co popisujete, neřeší podstatu problému, ale původní problém ignoruje a pak se ho snaží někde cestou dohonit. Nejste v tom sám, ve skutečnosti v tom s vámi jede velká část bezpečnostního IT průmyslu. A i tam to má jakousi historickou logiku, protože když je problém v bezpečnostním modelu proprietárních Windows, těžko mohou externisté ten problém opravit a jediné, co jim opravdu zbývá, je pokusit se ten problém dohonit někde venku. Předpokládám ale, že vy se ptáte na nějaké řešení v dlouhodobějším horizontu, které bude použitelné i ve světě, kde bude kladen velký důraz na ochranu soukromí, tudíž i na end-to-end šifrování komunikace.

Určitě souhlasím, i s analogií (uvedena výše) - můj pohled je určitě dlouhodobý a z určitého pohledu velice praktický. Pokud nedojde k podobné "revoluci" jako byl přechod od mainframů k osobním počítačům, pak nevidím jakoukoli možnost jak zapojit rozumnou bezpečnost do aplikačního rámce, který dnes existuje a každou minutou se zvětšuje. Jak na tomto fóru mnohokráte padlo - "patlalů je mnoho" a na opravdu odpovědný vývoj není čas ani peníze. Ve skutečnosti to nechceme mi - koncový zákazníci (ale to je jiná diskuse).

A protože žádný zásadní přerod na obzoru nevidím je potřeba najít řešení co vyřeší 80% problémů za 20% času (ale to znáte určitě lépe než já). A navíc jsem přesvědčen, že z nasazení řešení musí být vyloučena "veřejnost". Alespoň v současné době je IT security tak složitá, že je málo i lidí co všem vykládají, že tomu rozumí. A těch, co tomu opravdu rozumí je ještě dramaticky méně  ;) Ve skutečnosti si myslím, že celé IT je zbytečně složité - ale to je zase jiná diskuse.

Takže se snažím najít ideálně jednu oblast, kde se dnešní IT potkává - aplikace to z mého pohledu nejsou, OS také ne... Zbývá komunikační protokol, BIOS a HW (velice zjednodušeno).

Je více než pravděpodobné, že se pletu - ale začít někde musíme.

PanSauron

Re:Packet inspection vs. šifrování
« Odpověď #13 kdy: 31. 01. 2017, 10:25:26 »
Dekuju za postrehy, ale prijde mi, ze se porad nechapem.

@Franto, kdyz dam uzivateli QubesOS tak se po......

Zminujete delat updaty softwaru hmmm to je sice hezky, jenze to nemusite ani tuseni o tom, ze vam neco na system prolezlo, sebralo si to co chtelo a zase to odeslo. (https://securelist.com/analysis/publications/75533/faq-the-projectsauron-apt/). Uznavam, ze modelova situace byla asi prilis obecna, nicmene porad vidime, ip,uri a jine casti paketu. Dobre uvedu dalsi priklad, webrtc, to je taky takova vychytavka a defakto treba exposnete zarizeni na interni siti a zjistite o nem nektere detaily (treba u emailu muzete hlavicky vyfiltrovat). Kdyz jsme u tech mailu (tam je defakto stesti, ze to mate "v plaintextu"), ale i tak malware v obrazcich a steganografie ... uz vidim ten antivirak jak to procedi. Navic neni az takovej problem libovolnej antivirak obejit, zalezi jestli to chcete udelat jednou nebo vickrat atd.

Takze zpatky k tematu, nebo je to opravdu tak neresitelny problem analyzovat sitovy provoz, rozume, sofistikovane a vytvaret na zaklade toho pravidla (soft/hard)?

Nehci nahrazovat ani AV za IDS ani IDS za AV ani Updaty za AV ani Updaty za IDS ani IDS za Updaty. Z toho clanku co jsem sem pastnul tak je evidentni, ze AV se nechyta a jediny diky cemu to zachytili byl sitovej provoz. Jenze to muze bejt cim dal vetsi problem, kdyz mi to zacne uploadovat kocicky se stegano na nejakej ukradnutej FB ucet. Ja chapu, ze do jisty miry je to neresitelnej problem, ale z 10% uspesnosti by se treba 50% udelat dalo ne?

Kdyz to reknu treba jeste jinak, vsichni tady jedou nejaky AdBlock like rozsireni, ale jedna z variant je si to nastavit na FW a nemusim mit rozsireni a bude mi to fachat i na smartfounech.

Franta <xkucf03/>

Re:Packet inspection vs. šifrování
« Odpověď #14 kdy: 31. 01. 2017, 23:59:22 »
Dej uživateli nástroj, aby mu prohlížeč běžel v „sandboxu“ a nemohl ohrozit jeho data a ostatní aplikace běžící na jeho počítači. Zajisti, aby proces prohlížeče mohl přistupovat jen k serverům na internetu a nemohl se připojovat k ničemu na LAN
xkcd: Authorization

Jistě, jde o oddělení jednotlivých aplikací potažmo bezpečnostních úrovní, které jsou dnes běžně sesypané do jednoho kontextu a běží pod uživatelským účtem se stejnými právy. O nějakého roota tady zrovna moc nejde (to je samozřejmost a nutné minimum).

Jinou úroveň si zaslouží běžné brozudání po webu nebo dokonce po pochybných webech, jinou práce se soukromými daty (fotky, pracovní soubory atd.) jinou e-mail a další komunikace a dešifrování a podepisování tajných věcí.