W dniu 2017-12-19 o 17:14, Krzysztof Halasa pisze:
>
> 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.

W każdym razie karty Paywave potrafią
> robić bezstykowo kryptografię asymetryczną.

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 :)

>
> Główną zaletą kryptografii asymetrycznej jest tu możliwość potwierdzenia
> przez terminal autentyczności karty i transakcji, bez udziału banku,
> a więc także bez potrzeby zestawiania szyfrowanego kanału karta - bank.

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.

>> Taki AES (do
>> przodu) to tylko 100 linijek kodu, a SHA256 to 65 linijek (sam kod,
>> bez deklaracji z pliku .h) - w sumie malutkie programiki.
>
> Jasne. Zakładam, że sprawdzasz zgodność wyników z normalnie stosowanymi
> implementacjami (spotkałem się z przypadkiem odmiennym) :-)

Jak pisałem (z 10 lat temu) to nie znałem żadnych normalnie stosowanych
implementacji (i nadal nie znam - kiszę się we własnym sosie :) ).
Sprawdziłem tylko wektory testowe z dokumentów NIST i wszystko przeszło.
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 :).

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.

> 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ć.
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".
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.


> Problem z przechowywaniem to jedno, a kto ten klucz generuje (a więc ma
> do niego dostęp, choćby potencjalnie) to drugie.

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ć.
P.G.

do góry

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

do góry

W dniu 2017-12-21 o 16:59, Krzysztof Halasa pisze:
> 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.

Jeżeli klucz publiczny organizacji jest też z karty to według mnie
terminal może jedynie stwierdzić, że wszystkie klucze i podpisy na
karcie są spójne ze sobą. Musi mieć jakąś możliwość zweryfikowania
klucza publicznego organizacji płatniczej. Chyba nie może go pobierać z
karty a powinien mieć z innego pewnego źródła.

>
>> 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.

W krypto jak się cokolwiek pomyli to wychodzi totalna kaszana. Błąd był
we fragmencie kodu który nie był wykonywany przy żadnym z wektorów. Tego
jestem pewien. Natomiast nie jestem na 100% pewien czy to było w HMac.
Próbowałem teraz obejrzeć moje źródła, czy mi się przypomni jak to
wyglądało, ale nie. Podejrzane są wszystkie fragmenty if() bo warunek
może nie być spełniony. Kojarzy mi się, że to było pod koniec funkcji,
ale akurat w 2 funkcjach jakie mam w HMac (Init i Finish) widzę tylko
jedno if() i nie pod koniec. Pod koniec jest w funkcji Update mojej
klasy Hash, ale jakby tu był błąd to by wyszło przy innych wektorach
testowych, bo ta Update jest używana przez wszystkie jej klasy pochodne
(Md5, Sha1, Sha256, Sha512). HMac jej używa pośrednio bo dostaje
wskaźnik której funkcji mieszającej ma używać.
Że też sobie nie zostawiłem gdzieś tam komentarza "tu był byk" :(.
Miałbym szansę może dojść do tego, ale musiałbym dużo czasu poświęcić, a
tego akurat wyjątkowo brakuje. Robimy, coś, co musi być jeszcze w tym
roku wysłane i zainstalowane, a my dopiero ustalamy i testujemy
protokoły krypto do tego.

>> 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.

Niedawno widziałem gdzieś informację, że jakiś scalak od lat używany
chyba do RSA generował średnio 50% kluczy słabych (nie wiem na czym
polegają słabe klucze jak mają z góry narzuconą długość, ale nie znam się).

> 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.

Tylko trzeba ufać, że:
- jest faktycznie niszczony,
- jak w datasheet IC piszą, że nie ma funkcji do odczytania
wygenerowanego klucza prywatnego to jej faktycznie nie ma.

Chyba w 2013 odwiedził nas jakiś gość, który chciał nam wcisnąć jakiś
system kart i scalaki do czytników do tego (nie tanie). Potem jeszcze
nas dopadł na Securexie 2014 i był tak namolny, że zgodziliśmy się
usiąść i pogadać. Z rozmowy wychodziło, że karty są na prawdę super.
Tylko, że wszystkie klucze były generowane przez nich i wszystko się
opierało na "Ale my, jak ktoś wykupuje zestaw kart master, to zapominamy
o tych kluczach".
Był bardzo zdziwiony, że nie wykazujemy zainteresowania, bo inne firmy
to wzięły chociaż próbki scalaków i kart.
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:p1h5rc$f4m$1$P...@n...chmurka.ne
t...
>Chyba w 2013 odwiedził nas jakiś gość, który chciał nam wcisnąć jakiś
>system kart i scalaki do czytników do tego (nie tanie). Potem jeszcze
>nas dopadł na Securexie 2014 i był tak namolny, że zgodziliśmy się
>usiąść i pogadać. Z rozmowy wychodziło, że karty są na prawdę super.
>Tylko, że wszystkie klucze były generowane przez nich i wszystko się
>opierało na "Ale my, jak ktoś wykupuje zestaw kart master, to
>zapominamy o tych kluczach".
>Był bardzo zdziwiony, że nie wykazujemy zainteresowania, bo inne
>firmy to wzięły chociaż próbki scalaków i kart.

Zrobilby tanie to by teraz NSA/CIA/Mosad mieli dojscie do wielu
miejsc.
A tak to nie maja.

Chyba ze ... oprogramowanie demonstracyjne/deweloperskie do nich jest
trojanem :-)

J.

do góry

Użytkownik "Animka" napisał w wiadomości grup
dyskusyjnych:p0lvo8$rj9$...@n...icm.edu.pl...
>http://technowinki.onet.pl/hakerzy-zaatakowali-mobi
lne-aplikacje-najwiekszych-polskich-bankow/5pxwce

A tak swoja droga - jak myslicie, kto to tak hakuje ?

Rumuni/Bułgarzy/Rosjanie/Ukraincy/Arabowie/Murzyni, czy rodzimi
specjalisci ?

Hakerzy-idealisci, biedni studenci, zwolnieni informatycy, nowoczesna
mafia ?

Bo nasilenie tego sugeruje zorganizowane akcje.

J.

do góry

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

> Jeżeli klucz publiczny organizacji jest też z karty to według mnie
> terminal może jedynie stwierdzić, że wszystkie klucze i podpisy na
> karcie są spójne ze sobą.

Jasne. Klucz (klucze) organizacji - także w terminalu.

> W krypto jak się cokolwiek pomyli to wychodzi totalna kaszana.

Właśnie.

> Błąd
> był we fragmencie kodu który nie był wykonywany przy żadnym z
> wektorów. Tego jestem pewien. Natomiast nie jestem na 100% pewien czy
> to było w HMac.

Dziwne jest to, że typowo nie ma takiego kodu, który nie byłby
wykonywany przy żadnym z (np. kilku) wektorów.

> Niedawno widziałem gdzieś informację, że jakiś scalak od lat używany
> chyba do RSA generował średnio 50% kluczy słabych (nie wiem na czym
> polegają słabe klucze jak mają z góry narzuconą długość, ale nie znam
> się).

Np. na przewidywalnym rozkładzie, albo mogą być łatwe do faktoryzacji.
Normalnie sprawdza się klucze pod tym kątem.

> Tylko trzeba ufać, że:
> - jest faktycznie niszczony,
> - jak w datasheet IC piszą, że nie ma funkcji do odczytania
> wygenerowanego klucza prywatnego to jej faktycznie nie ma.

Owszem, przy czym ja generalnie bym temu nie ufał, oraz znane są
"wysokoprofilowe" przypadki, w których rzekomo niszczone klucze po
pewnym czasie znalazły się w niewłaściwych rękach (właściwe = m.in.
służb). Ale to wszystko kwestia wartości zabezpieczanych - jeśli
ryzykujemy np. sumami typu setek czy tysięcy zł, to te klucze zapewne
się nie znajdą - informacja o tym, że nie są niszczone jest cenniejsza
(choć w gruncie rzeczy każdy powinien to założyć).

> Tylko, że wszystkie klucze były generowane przez nich i wszystko się
> opierało na "Ale my, jak ktoś wykupuje zestaw kart master, to
> zapominamy o tych kluczach".

W nieco poważniejszych zastosowaniach o takich rzeczach często nie ma
mowy. Aczkolwiek różnie może być.

> Był bardzo zdziwiony, że nie wykazujemy zainteresowania, bo inne firmy
> to wzięły chociaż próbki scalaków i kart.

Próbki zawsze można wziąć. Nawet gdyby miały leżeć na półce przez rok :-)
--
Krzysztof Hałasa

do góry

W dniu 2017-12-23 o 01:38, Krzysztof Halasa pisze:
>> Błąd
>> był we fragmencie kodu który nie był wykonywany przy żadnym z
>> wektorów. Tego jestem pewien. Natomiast nie jestem na 100% pewien czy
>> to było w HMac.
>
> Dziwne jest to, że typowo nie ma takiego kodu, który nie byłby
> wykonywany przy żadnym z (np. kilku) wektorów.

Tak. To jest dziwne.
Z własnej ciekawości chciałbym to sobie też przypomnieć, ale teraz
absolutnie nie mam czasu robić dochodzenia. Może w nowym roku.
Nie lubię pisać niepewnych informacji, a za dawno było, abym był pewien.
Możliwe, że wrzucili jakieś 3 krótkie wektory i żaden nie doprowadzał do
przejścia do kolejnego bloku i to powodowało że jakiś kawałek nie był
potrzebny, a ktoś kto wstawiał wektory właśnie tak pomyślał, że jak dla
trzech przejdzie to nie ma siły, aby coś było nie tak.
Zdaję sobie sprawę, że dopóki nie pokażę konkretnie to jestem mało
wiarygodny, ale nie wiem, czy mam szansę pokazać konkretnie :)

>> Tylko, że wszystkie klucze były generowane przez nich i wszystko się
>> opierało na "Ale my, jak ktoś wykupuje zestaw kart master, to
>> zapominamy o tych kluczach".
>
> W nieco poważniejszych zastosowaniach o takich rzeczach często nie ma
> mowy. Aczkolwiek różnie może być.

Gość twierdził, że niektóre banki w Polsce używają tego systemu bo karty
mają jakieś atesty.
Po wpłaceniu kilku kilo Euro (za wejście do systemu) mielibyśmy dostać
jakąś dokumentację. Ale nie umiałem z gościa (handlowca) wydębić
informacji na ile dokładna byłaby to dokumentacja. Miała umożliwić
produkcję czytników z wykorzystaniem ich scalaków i bycie kompatybilnymi
z innymi systemami wykorzystującymi te karty i te scalaki.
W szczególności nie udało mi się ustalić, czy byłby tam opis
zastosowanych algorytmów.
Opieram się na założeniu (wiem, że nie 100% prawidłowym) - jawne
algorytmy = dobry system, tajne algorytmy = podejrzany (być może słaby)
system.
W sumie stanęło na tym, że nie widzimy powodu, aby kupować kota w worku.
P.G.

do góry

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

> Gość twierdził, że niektóre banki w Polsce używają tego systemu bo
> karty mają jakieś atesty.

No tak, ale wymagany poziom bezpieczeństwa związany z jakimś tam
bankowym kontem (np. nawet nie firmowym) nie jest wysoki. W końcu jest
wiele innych, prostych metod by dobrać się do konta.

> Po wpłaceniu kilku kilo Euro (za wejście do systemu) mielibyśmy dostać
> jakąś dokumentację. Ale nie umiałem z gościa (handlowca) wydębić
> informacji na ile dokładna byłaby to dokumentacja. Miała umożliwić
> produkcję czytników z wykorzystaniem ich scalaków i bycie
> kompatybilnymi z innymi systemami wykorzystującymi te karty i te
> scalaki.
> W szczególności nie udało mi się ustalić, czy byłby tam opis
> zastosowanych algorytmów.

Ciekawe który to "system". To były karty stykowe, ISO/IEC 14443 A,
a może B? Jeszcze inne?

> Opieram się na założeniu (wiem, że nie 100% prawidłowym) - jawne
> algorytmy = dobry system, tajne algorytmy = podejrzany (być może
> słaby) system.

Jawne algorytmy muszą dodatkowo być prawidłowe i prawidłowo zastosowane,
no i nikt nie wie kiedy zostaną złamane. Ale faktycznie, tajny system =
bardzo bardzo często słaby system.
--
Krzysztof Hałasa

do góry

W dniu 2018-01-01 o 21:58, Krzysztof Halasa pisze:
> Piotr Gałka <p...@c...pl> writes:
>
>> Gość twierdził, że niektóre banki w Polsce używają tego systemu bo
>> karty mają jakieś atesty.
>
> No tak, ale wymagany poziom bezpieczeństwa związany z jakimś tam
> bankowym kontem (np. nawet nie firmowym) nie jest wysoki.

Ja piszę o kontroli dostępu a nie o kartach do konta.

> Ciekawe który to "system". To były karty stykowe, ISO/IEC 14443 A,
> a może B? Jeszcze inne?

Jak pierwszy raz wspomniałem to nie pamiętałem nazwy (w końcu to było
2013/2014), potem mi się przypomniała: Legic.
Według nazwy trafiam na:

http://www.legic.com/home/

ale się nie wczytywałem.

> Jawne algorytmy muszą dodatkowo być prawidłowe i prawidłowo zastosowane,
> no i nikt nie wie kiedy zostaną złamane. Ale faktycznie, tajny system =
> bardzo bardzo często słaby system.

O krypto wiem tyle ile wyczytałem z książki Ferguson, Schneier:
"Kryptografia w praktyce". Jest chyba inna od większości książek z tej
dziedziny bo właśnie skupia się nie na algorytmach tylko na praktyce,
ale nie mam porównania - dlatego "chyba".
Z jakiegoś jej fragmentu (napisana w 2003) wynikało mi, że do mifare
clasic należy podejść z wielką ostrożnością i się potwierdziło.
P.G.

do góry