Piotr Gałka <p...@c...pl> writes:

>> Scalaki są coraz szybsze i jedzą coraz mniej prądu. Kwestia także jak
>> długo on to ma (może) liczyć.
>
> Chyba coś do 100ms.

To dość długo nawet.

> Budzi moje wątpliwości ale skoro wiesz to spróbuję zapamiętać, ale nie
> wykluczam, że jak podobny temat wyjdzie za rok to znów będę na
> poziomie tego, co mi się wydaje :)

google fast dynamic data authentication.

> A tak na chłopski rozum parę słów dokładniej. Bez użycia słowa
> certyfikat, za to z użyciem słów klucz prywatny i publiczny. Gdzie
> który siedzi i kto co liczy.
> Rozumiem, że bez zestawiania połączenia - czyli wszystko jest na
> miejscu.

Owszem. Certyfikat = klucz publiczny (np. karty), podpisany kluczem
prywatnym (np. banku). Klucz publiczny banku (także na karcie) podpisany
kluczem prywatnym organizacji płatniczej. Klucz publiczny organizacji -
na karcie. Tym sposobem karta może podpisać dowolną informację swoim
kluczem, a terminal - bez udziału banku - może stwierdzić, że podpis
jest prawidłowy i pochodzi od karty wydanej w ramach organizacji.

> Potem jednak znalazłem błąd (prawie na pewno w HMAC) i napisałem do
> NIST, że mają źle dobrane wektory testowe bo mi się udało zrobić błąd
> którego one nie wykrywają i załączyłem moje źródła z wskazaniem gdzie
> jest błąd. Nic mi nie odpowiedzieli, ale jak sobie po jakimś czasie
> przypomniałem o tym i zajrzałem na ich stronę to zamiast chyba 3
> wektorów było już coś koło 10 i chyba wszystkie nowe wyłapywały ten
> mój błąd :).

Ciekawe. To musiał być jakiś subtelny błąd.

> Teraz już mam sprawdzone (pośrednio) z normalnie stosowanymi
> implementacjami - moje programy komunikują się z urządzeniami z
> którymi ktoś korzystający z jakichś bibliotek krypto też się łączy.

Słusznie. Szansa na błąd, jeśli typowo dostajemy dobre wyniki (zgodne
z innymi, powszechnie używanymi implementacjami) jest bardzo mała.
W szczególności w niskopoziomowym kodzie.

>> bez kryptografii asymetrycznej nie mamy niezaprzeczalności zlecenia operacji.
>
> Czy dobrze myślę, że jak coś podpisze kluczem prywatnym to nikt inny
> nie może tego zrobić.

Właśnie. Pod pewnymi warunkami, oczywiście - np. nikt inny nie mógł mieć
nigdy dostępu do klucza prywatnego karty.

> A jakby podpisał kluczem symetrycznym to ten klucz musiałby też znać
> bank, a to oznacza, że mogło by być domniemanie, że klucz wyciekł z
> banku więc "to nie ja podpisałem".

Ano.

> Ale jak założymy, że klucz mógł wyciec z banku to dlaczego mamy
> pewność, że klucz prywatny nie wyciekł w momencie gdy był
> generowany/dostarczany.

To jest pewien problem. W zastosowaniach niebankowych użytkownik sam
może wygenerować klucz, ale tu mamy do czynienia z nieprofesjonalistą.
Tu opiera się to zwykle na procedurach i certyfikatach, co oczywiście
jest lepsze niż nic, ale może być zawodne.

> Ale w przypadku kart to klucz mógłby być generowany w banku i od razu
> wpisywany na kartę i do jakiejś specjalnego urządzenia do którego
> miałby dostęp serwer, ale które nie udostępniało by tych kluczy a
> jedynie pozwalało weryfikować prawidłowość jakiegoś podpisu - nad
> szczegółami można by się zastanowić.

Tak czy owak, jeśli serwer ma dostęp, to jego obsługa także ma dostęp,
a przynajmniej może taki dostęp (być może w drodze "spisku") uzyskać.
Im bardziej to skomplikowane tym mniejsza szansa na to, że jest
bezpieczne. Sytuacja, w której klucz jest generowany (poza kartą lub
przez samą kartę), zapisywany i następnie niszczony (jeśli istniał poza
kartą) jest lepsza.
--
Krzysztof Hałasa