Podpis maleho objemu dat

Miroslav Šinko sinkomiro na gmail.com
Pátek Červenec 12 01:34:31 CEST 2024


Myslim, ze okrem plavajuceho kluca ziadne z tu prezentovanych rieseni 
nebrani podvrhu. Ak si utocnik odchti packet a zopakuje ho, tak 
prijimacia strana nezisti podvrh. Nech je algoritmus podpisu akykolvek, 
pri zopakovani binarneho obrazu dat to proste bude sediet.
Podpisovanie dat sa bezne pouziva, ale nie ako jedina metoda 
zabezpecenia. Napr. QR kody cestovnych listkov obsahuju data + podpis. 
OK, pouzijem ho raz, validacia overi pravost. Ale ked si urobim kopiu 
(bez akejkolvek namahy na kopirke, alebo fotakom mobilu) a pouzijem ju, 
tak ma odchyti passback, fraudulent use, alebo iny mechanizmus. V 
pripade jednorazoveho listka je zamietnutie okamzite. Vsetko vychadza z 
toho, ze validacna strana si pamata uz raz pouzite data.

V pripade par bytovych povelov zariadeniu, kde sa dany povel moze, a z 
principu aj v case bude opakovat, nestaci jednoduche podpisovanie. 
Prijimacia strana nezisti podvrh packetu odchyteneho a odvysielaneho 
1:1. Do dat treba pridat aspon nejake pocitadlo (to je nieco ako 
plavajuci kod), alebo realny cas, ktory sa spolu s uzitocnymi datami 
podpise. Pri zopakovani odchyteneho packetu prijimacia strana bude 
vediet vyhodnotit, ze stav pocitadla, alebo realny cas su stare.

miro

On 11.7.2024 10:58, Pavel Kořenský wrote:
> Zdravím,
> 
> ještě mně napadlo, že pokud to použitý procesor umožňuje, bylo by možné 
> použít klasický HMAC s dohodnutým tajným klíčem (dohodnutý salt) a 
> hashem dle SHA256. A posílat třeba jen poslední dva byty toho hashe.
> Přijímací strana si udělá také SHA256 z přijatých dat a prověří, že se 
> poslední dva byty hashe shodují.
> Pochopitelně to není úplně neprůstřelné a člověk se nezbaví otravného 
> managementu hesel, pokud je těch zařízení víc nebo dokonce mnoho. Ale je 
> to výrazně lepší než XOR i když mnohem pomalejší.
> 
> Zdraví PavelK
> 


Další informace o konferenci Hw-list