http://technowinki.onet.pl/hakerzy-zaatakowali-mobilne-aplikacje-najwiekszych-polskich-bankow/5pxwce

--
animka

W dniu 11-12-17 o 14:03, Animka pisze:

http://technowinki.onet.pl/hakerzy-zaatakowali-mobilne-aplikacje-najwiekszych-polskich-bankow/5pxwce

Gdy bankowość zaczynała wchodzić do Internetu konieczne było
zabezpieczenie tych transakcji. Stosowano różne wybiegi, ale generalnym
założeniem było wykorzystanie dwóch niezależnych kanałów. Sposobów było
kilka, a jednym z nich było równoległe wysyłanie kodu SMS. Sposób
wydawał się dobry, bowiem za mało prawdopodobne uznawano jednoczesną
utratę kontroli nad telefonem komórkowym i komputerem podłączonym do
Internetu.

Upowszechnienie dostępu do internetu za pośrednictwem urządzeń
wykorzystujących GSM spowodowało upowszechnienie "apek", tylko nikt nie
myśli o tym, że w ten sposób dochodzi do naruszenia podstawowych zasad
bezpieczeństwa.nie mamy już dwóch niezależnych kanałów, tylko jeden.

Jesli ktoś potrzebuje korzystać z "apek", to powinien mieć albo inny
telefon do odbierania kodów SMS, albo wykorzystywać inny sposób
zabezpieczenia.

W dniu 2017-12-11 o 17:16, Robert Tomasik pisze:

W dniu 11-12-17 o 14:03, Animka pisze:

http://technowinki.onet.pl/hakerzy-zaatakowali-mobilne-aplikacje-najwiekszych-polskich-bankow/5pxwce

Gdy bankowość zaczynała wchodzić do Internetu konieczne było
zabezpieczenie tych transakcji. Stosowano różne wybiegi, ale generalnym
założeniem było wykorzystanie dwóch niezależnych kanałów. Sposobów było
kilka, a jednym z nich było równoległe wysyłanie kodu SMS. Sposób
wydawał się dobry, bowiem za mało prawdopodobne uznawano jednoczesną
utratę kontroli nad telefonem komórkowym i komputerem podłączonym do
Internetu.

Upowszechnienie dostępu do internetu za pośrednictwem urządzeń
wykorzystujących GSM spowodowało upowszechnienie "apek", tylko nikt nie
myśli o tym, że w ten sposób dochodzi do naruszenia podstawowych zasad
bezpieczeństwa.nie mamy już dwóch niezależnych kanałów, tylko jeden.

Jesli ktoś potrzebuje korzystać z "apek", to powinien mieć albo inny
telefon do odbierania kodów SMS, albo wykorzystywać inny sposób
zabezpieczenia.

Najlepiej nie instalować tych aplikacji i mieć telefon tylko dla siebie.
Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.



--
animka

W dniu 11-12-17 o 21:54, Animka pisze:

Najlepiej nie instalować tych aplikacji i mieć telefon tylko dla siebie.

Albo mieć dwa telefony. Na jednym apkę, a na drugim SMS-y odbierać.

Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.

Zbliżeniowy spokojnie można ogarnąć technicznym zabezpieczeniem portfela.

W dniu 2017-12-11 o 23:15, Robert Tomasik pisze:

W dniu 11-12-17 o 21:54, Animka pisze:

Najlepiej nie instalować tych aplikacji i mieć telefon tylko dla siebie.

Albo mieć dwa telefony. Na jednym apkę, a na drugim SMS-y odbierać.

Komu by sie chciało nosić ze sobą 2 telefony :-(
Dla mnie za ciężkie.

Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.

Zbliżeniowy spokojnie można ogarnąć technicznym zabezpieczeniem portfela.

Nie bardzo rozumiem.
Zadzwonilam do Banku, powiedziano mi, że zablokują, ale żebym wykonała jedna czy dwie operacje w bankomacie I mam spokój. Wolę wklepać pin.
Jedna babka jak przyłożyła telefon do czytnika to jej pobrało ze 2 razy. Pewnie za długo przytrzymywała.


--
animka

W dniu 11-12-17 o 23:51, Animka pisze:

Najlepiej nie instalować tych aplikacji i mieć telefon tylko dla siebie.

Albo mieć dwa telefony. Na jednym apkę, a na drugim SMS-y odbierać.

Komu by sie chciało nosić ze sobą 2 telefony :-(
Dla mnie za ciężkie.

Ile osób potrzebuje mieć możliwość wykonywania przelewów pełnego alda
swojego rachunku z telefonu?

Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.

Zbliżeniowy spokojnie można ogarnąć technicznym zabezpieczeniem portfela.

Nie bardzo rozumiem.

"Puszka Faraday'a" :-)

Zadzwonilam do Banku, powiedziano mi, że zablokują, ale żebym wykonała
jedna czy dwie operacje w bankomacie I mam spokój. Wolę wklepać pin.

Też sposób.

Jedna babka jak przyłożyła telefon do czytnika to jej pobrało ze 2 razy.
Pewnie za długo przytrzymywała.

Nie za bardzo możliwe. Ktoś musiał dwa razy wysłać obciążenie.

W dniu 2017-12-11 o 23:57, Robert Tomasik pisze:

W dniu 11-12-17 o 23:51, Animka pisze:

Najlepiej nie instalować tych aplikacji i mieć telefon tylko dla siebie.

Albo mieć dwa telefony. Na jednym apkę, a na drugim SMS-y odbierać.

Komu by sie chciało nosić ze sobą 2 telefony :-(
Dla mnie za ciężkie.

Ile osób potrzebuje mieć możliwość wykonywania przelewów pełnego alda
swojego rachunku z telefonu?

Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.

Zbliżeniowy spokojnie można ogarnąć technicznym zabezpieczeniem portfela.

Nie bardzo rozumiem.

"Puszka Faraday'a" :-)

Nie kojarzę tego z telefonem. Tępa jestem.

Zadzwonilam do Banku, powiedziano mi, że zablokują, ale żebym wykonała
jedna czy dwie operacje w bankomacie I mam spokój. Wolę wklepać pin.

Też sposób.

Jedna babka jak przyłożyła telefon do czytnika to jej pobrało ze 2 razy.
Pewnie za długo przytrzymywała.

Nie za bardzo możliwe. Ktoś musiał dwa razy wysłać obciążenie.

Mogło i tak być.


--
animka

Jedna babka jak przyłożyła telefon do czytnika to jej pobrało ze 2 razy.
Pewnie za długo przytrzymywała.

Nie za bardzo możliwe. Ktoś musiał dwa razy wysłać obciążenie.

Mogło i tak być.

Mnie też się tak zdarzyło.
Za pierwszym razem wykazało błąd. Kasjerka coś za późno/źle uruchomiła?
Za drugim razem było ok.
Na rachunku pokazały się dwie operacje na tą samą sumę "nierozliczone",
ale obie sumy zablokowane.
Za dwa dni operacje zostały rozliczone i tylko jedna operacja obciążyła konto.
Różne są efekty zbliżeniowej płatności..:)

Piotr W.

W dniu 2017-12-12 o 20:05, Piotr W. pisze:

Jedna babka jak przyłożyła telefon do czytnika to jej pobrało ze 2 razy.
Pewnie za długo przytrzymywała.

Nie za bardzo możliwe. Ktoś musiał dwa razy wysłać obciążenie.

Mogło i tak być.

Mnie też się tak zdarzyło.
Za pierwszym razem wykazało błąd. Kasjerka coś za późno/źle uruchomiła?
Za drugim razem było ok.
Na rachunku pokazały się dwie operacje na tą samą sumę "nierozliczone",
ale obie sumy zablokowane.
Za dwa dni operacje zostały rozliczone i tylko jedna operacja obciążyła konto.
Różne są efekty zbliżeniowej płatności..:)

Dlatego ja zbliżeniowość mam w ciężkim poważaniu, Nie chcę się po prostu denerwować.


--
animka

W dniu 2017-12-11 o 21:54, Animka pisze:

Zbliżeniowość też jest zbdnym dodatkiem i lepiej to zablokować.

Mi się nie podoba offlajnowość i bezpinowość.
A do zbliżeniowości nic specjalnie nie mam. Tylko, że bez znajomości kluczy to powinna udostępniać tylko niezbędne minimum - chyba identyfikacja organizacji płatniczej by wystarczyła.
P.G.

Paranoje zawsze mają dwa oblicza.
Ja wolę nie wpisywać PINu - jak mi kartę ukradną, to będą musieli po 50zł kraść w sklepach, a z bankomatu nie wypłacą (pomijając dziurę w EMV - więc może wypłacą - ale może tą dziurę w nowych kartach załatali).
Podejrzeć PIN kamerą i nasłać kieszonkowca - żadna sztuka, a potem prędziutko do bankomatu i pod korek wypłata - mało kto zawraca sobie głowę zmianą limitów, szczególnie na kredytówkach - a niektóre banki, jak citek, przy innych zaletach, w ogóle na to nie pozwalają.

W dniu 2017-12-12 o 11:22, Dawid Rutkowski pisze:

Paranoje zawsze mają dwa oblicza.
Ja wolę nie wpisywać PINu - jak mi kartę ukradną, to będą musieli po 50zł kraść w sklepach, a z bankomatu nie wypłacą (pomijając dziurę w EMV - więc może wypłacą - ale może tą dziurę w nowych kartach załatali).
Podejrzeć PIN kamerą i nasłać kieszonkowca - żadna sztuka, a potem prędziutko do bankomatu i pod korek wypłata - mało kto zawraca sobie głowę zmianą limitów, szczególnie na kredytówkach - a niektóre banki, jak citek, przy innych zaletach, w ogóle na to nie pozwalają.

Ciągle zapominam, że z tego, że ja nie używam KK w bankomacie nie wynika, że się nie da :(, a mam w pamięci ten przykład jak w kilka godzin wybrali (jakiejś kobiecie we Wrocławiu) kilka kPLN transakcjami po 50zł i te dwie rzeczy determinują moje (jak widać, nie do końca przemyślane) zdanie.
Do tego, bardzo rzadko mi się zdarzają transakcje poniżej 50zł więc i tak każda transakcja mi się kojarzy z koniecznością PINu.
To, że KK nie da się w bankomacie to mi się pewnie wbiło przez to, że od chyba 8 lat mam ustawiony (KK mBanku) limit gotówkowy na 0.

Coś mi chodzi po głowie, że w Citku limit gotówkowy jest połową limitu karty. Muszę się w końcu wziąć za ustawienie tego limitu.
P.G.

W citku chyba tego nie ruszysz.
Jedyne ograniczenie to dzienny limit wypłaty z bankomatu - 5k dla kart z segmentu silver (w tym simplicity), 10k dla gold (+premier miles i world), 15k dla platyn i "czarnej" - oraz liczba wypłat - 6 dla segmentu silver, 8 dla pozostałych.
Możesz ew. próbować z "limitem wypłat gotówkowych", który pokazany jest na wyciągu - u mnie jest równy limitowi karty. Jakby to wyzerować czy ustawić na jakiś mały, to problem byłby rozwiązany - np. w db tak mam - 1500zł i 1 wypłata dziennie - a muszę zobaczyć, jak to mam na KK wbk.

Ale w te kilka k transakcjami po 50zł to obecnie nie wierzę - z resztą banki wydają się o tym wiedzieć i karty konfigurują - wg mnie - bardziej lamersko.
Moja KK db sprzed wznowienia, po wsadzeniu w paszczę terminala, pozwalała na pikaczowe offline'y przez kilka tygodni - a po wznowieniu pozwala najwyżej na kilka piknięć. Ta nowa z wbk jeszcze ani razu nie poszła offline.
Więc jakby się coś takiego dziwnego zaczęło dziać, to bank zadzwoni - albo sam kartę zablokuje.

W dniu 2017-12-12 o 12:33, Dawid Rutkowski pisze:

W citku chyba tego nie ruszysz.

Ja myślę o zdecydowaniu jaki chcę limit KK i jego obniżenie. Bo jak dawali kartę to na limit nie miałem wpływu.
Pół roku minęło i nie miałem czasu na poważne zastanowienie. Logowałem się do systemu tylko raz na miesiąc aby pobrać wyciąg.

Możesz ew. próbować z "limitem wypłat gotówkowych", który pokazany jest na wyciągu - u mnie jest równy limitowi karty.

No to chyba źle pamiętałem. Może to w mBanku maksymalny gotówkowy jest połową całego.

Ale w te kilka k transakcjami po 50zł to obecnie nie wierzę

Też mam nadzieję, że teraz już niemożliwe, ale ciekawe jak to rozwiązali we Wrocławiu, bo to (z tego co wtedy czytałem) to tam dawało się do woli kupować jakieś bilety po 50zł w automatach w tramwajach czy autobusach, które to automaty nie miały w ogóle klawiatur.

Ta nowa z wbk jeszcze ani razu nie poszła offline.

Zastanawiam się, czy nie założyć konta (dla karty debetowej) w Orange. Przy okazji zapytałem - twierdzili, że nie da się zrobić debetu, ale nie udało mi się ustalić, czy rozumieją różnicę między online'owością a zbliżeniowością. A że kilka metrów obok jest mBank, to zapytałem w mBanku o karty Orange i tu wyglądało, że się rozumiemy i uzyskałem potwierdzenie, że wszystkie transakcje są online.
Może faktycznie.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Mi się nie podoba offlajnowość i bezpinowość.
A do zbliżeniowości nic specjalnie nie mam. Tylko, że bez znajomości
kluczy to powinna udostępniać tylko niezbędne minimum - chyba
identyfikacja organizacji płatniczej by wystarczyła.

A o jakich dokładnie kluczach myślisz?
--
Krzysztof Hałasa

W dniu 2017-12-15 o 17:48, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Mi się nie podoba offlajnowość i bezpinowość.
A do zbliżeniowości nic specjalnie nie mam. Tylko, że bez znajomości
kluczy to powinna udostępniać tylko niezbędne minimum - chyba
identyfikacja organizacji płatniczej by wystarczyła.

A o jakich dokładnie kluczach myślisz?

To było hasłowo. Miałem na myśli stan przed ustanowieniem sesji i po ustanowieniu (że po ustanowieniu już znamy jakieś klucze tej sesji).

Jak ja chcę się zalogować do banku to muszę w sposób jawny w przeglądarce podać adres strony logowania mojego banku. To wystarcza aby pojawiła się strona z kłódeczką - czyli dalej już może być szyfrowane.

Komunikację karty wyobrażałem sobie analogicznie. Czyli karta powinna jawnie podać jakiś adres, który pozwoli znaleźć odpowiednią "stronę" i ustanowić z nią tajną sesję.
To powinno wystarczyć. Tylko to by zapewne wymagało mocy obliczeniowej w karcie, która (na razie) jeszcze się tam nie chce zmieścić (w zbliżeniowych na pewno trudniej niż w stykowych).

O tym wtedy nie pomyślałem, bo się głębiej nie zastanowiłem.

Załóżmy, że w karcie możemy na razie wstawić tylko kryptografię symetryczną - czy da się zestawić takie połączenie.

Karta mówi z kim (hasłowo bankiem) się połączyć. Terminal ustanawia sobie sesję tak jak przeglądarka na komputrze. Brakuje tajnego połączenia między kartą a terminalem.
Gdyby karta miała jakiś klucz a do terminala ten klucz byłby dosyłany w sesji to mogliby tajnie pogadać. Ale gdyby ten klucz był jednakowy dla wszystkich kart tego samego banku to szybko by wyciekł.
Czyli musi być dla każdej karty inny.

Z tego by wynikało, że dopóki nie wstawimy większej mocy obliczeniowej w kartę to oprócz namiaru z kim się łączyć powinna ona jeszcze jawnie podać "kto ja jestem".

To już chyba powinno wystarczyć. Terminal dostaje klucz pasujący tylko do tej karty i gadają.
Żeby ktoś mający dostęp do terminala nie mógł sobie kolekcjonować tych kluczy to klucz powinien być za każdym razem inny. Czyli karta musi mieć jakiś dobry generator losowy (to jest według mnie możliwe). Do swojego numeru dorzuca tę liczbę i serwer wylicza klucz, który wysyła terminalowi (może serwer też powinien wrzucić jakąś losowość)

Choć właściwie może ta sesja symetryczna mogła by być w ten sposób ustanawiana między kartą a bankiem i terminal nie miałby wglądu w ich komunikację. Aby wysłać PIN miałby swoją sesję (chyba, że klawisze na karcie).

Krypto symetryczna jest chyba w zupełności wystarczająca dopóki każda para która chce ze sobą gadać ma szansę się spotkać i tajnie wymienić kluczami. Nie ma wtedy potrzeby istnienia kluczy publicznych, bo wszystkie mogą być tajne. Każda karta może się spotkać ze swoim bankiem przed jej wysłaniem do klienta i ustalić sobie z bankiem wspólne klucze.
To powinno wystarczyć.

Jakby ktoś ukradł kartę to można założyć, że będzie mógł wyszlifować jej klucz. Dlatego PIN nie powinien być w żaden sposób zapisany na karcie. Powinien być znany tylko serwerowi banku.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

[karty zbliżeniowe]

Komunikację karty wyobrażałem sobie analogicznie. Czyli karta powinna
jawnie podać jakiś adres, który pozwoli znaleźć odpowiednią "stronę" i
ustanowić z nią tajną sesję.

To wymaga przede wszystkim połączenia z bankiem, wtedy "klucze" to nie
problem. Ale miało być szybko, natychmiast.

To powinno wystarczyć. Tylko to by zapewne wymagało mocy obliczeniowej
w karcie, która (na razie) jeszcze się tam nie chce zmieścić (w
zbliżeniowych na pewno trudniej niż w stykowych).

Chce się mieścić i mieści się. Przynajmniej w części kart.

Załóżmy, że w karcie możemy na razie wstawić tylko kryptografię
symetryczną - czy da się zestawić takie połączenie.

Bez połączenia z bankiem - nie.

Gdyby karta miała jakiś klucz a do terminala ten klucz byłby dosyłany
w sesji to mogliby tajnie pogadać. Ale gdyby ten klucz był jednakowy
dla wszystkich kart tego samego banku to szybko by wyciekł.
Czyli musi być dla każdej karty inny.

Wciąż by wyciekał. Klucz musiałby być inny dla każdej sesji. Ale to jest
możliwe, tylko trzeba być online z bankiem. Problem.

Jakby ktoś ukradł kartę to można założyć, że będzie mógł wyszlifować
jej klucz. Dlatego PIN nie powinien być w żaden sposób zapisany na
karcie. Powinien być znany tylko serwerowi banku.

To drugi problem.
Kryptografia asymetryczna rozwiązuje te problemy, i właściwie nie ma
obecnie przeszkód technicznych w korzystaniu z niej.
Kryptografia symetryczna wymaga połączenia z bankiem (ma też inne wady)
i nie powinna być podstawą nowych rozwiązań.
--
Krzysztof Hałasa

W dniu 2017-12-15 o 23:51, Krzysztof Halasa pisze:

Komunikację karty wyobrażałem sobie analogicznie. Czyli karta powinna
jawnie podać jakiś adres, który pozwoli znaleźć odpowiednią "stronę" i
ustanowić z nią tajną sesję.

To wymaga przede wszystkim połączenia z bankiem, wtedy "klucze" to nie
problem. Ale miało być szybko, natychmiast.

Generalnie to zawsze ma być natychmiast :)
Ale odezwałeś, się, gdy napisałem, że karta powinna ujawniać tylko jakiś jeden adres kogoś (banku/organizacji płatniczej) z kim należy się połączyć - czyli według mnie dyskusja jest poza kontekstem "szybko, natychmiast".

Chce się mieścić i mieści się. Przynajmniej w części kart.

W stykowych, czy zbliżeniowych?

Spośród kart, które stosujemy (do kontroli dostępu) za najbardziej zaawansowane uważam DesFire - ale to jest poziom AES i CMAC.
Scalaczek, który liczy ECC wymaga kilkunastu mA podczas tych obliczeń. Nie bardzo go sobie wyobrażam w karcie _zbliżeniowej_.

Jakby ktoś ukradł kartę to można założyć, że będzie mógł wyszlifować
jej klucz. Dlatego PIN nie powinien być w żaden sposób zapisany na
karcie. Powinien być znany tylko serwerowi banku.

To drugi problem.
Kryptografia asymetryczna rozwiązuje te problemy, i właściwie nie ma
obecnie przeszkód technicznych w korzystaniu z niej.

Podejrzewam, że w przypadku kart zbliżeniowych są jeszcze przeszkody w jej stosowaniu.

Kryptografia symetryczna wymaga połączenia z bankiem (ma też inne wady)
i nie powinna być podstawą nowych rozwiązań.

Mógłbyś wymienić wady kryptografii symetrycznej, których nie ma asymetryczna?
Chodzi mi głównie o sytuację, gdy strony mogą się ze sobą spotkać (jak karta i bank) aby wymienić się kluczami.
Nie widzę powodów, aby w rozwiązaniu które ma takie założenie (o spotkaniu się) rozwiązanie musiało bazować na asymetrycznej.

Nie ogarnąłem jeszcze stosowania asymetrycznej więc nie mam praktycznego wyczucia. Wynika to między innymi z mojej ograniczoności informatycznej. Jestem w tej materii samoukiem i nie za bardzo mam na to czas. Na przykład nigdy się nie nauczyłem korzystać z gotowych bibliotek. Więc ogarniam tylko to co sobie sam napisałem. 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.

Jeśli za wadę uznać konieczność przechowywania tajnego klucza to według mnie asymetryczna nie ma tu żadnej przewagi.
Przeglądarka może się upewnić łańcuszkiem certyfikatów, że połączyła się z drugą stroną i jedynie serwer banku musi przechowywać tajny klucz prywatny. Ale serwer też musi się jakoś upewnić z kim rozmawia.
Na razie użytkownik identyfikuje się za pomocą hasła (zazwyczaj dość słabego). Gdyby użytkownikiem miało być urządzenie (karta) to pojawia się konieczność przechowania tego hasła (lub lepiej klucza prywatnego).
Problem z przechowaniem jest taki sam jak z kluczem symetrycznym.
Dlatego w tym aspekcie nie widzę zalet asymetrycznej.
P.G.

Karty chyba jakieś klucze - po coś w końcu mają chip - np. jakiś czas temu była afera, że wyciekły z gemalto klucze chyba do kart sim.
Przy pikaczu chyba jednak robotę wykonuje tylko terminal - karta daje niewiele więcej niż z paska, jedynie jednorazowe cvv, generowane na podstawie ATC, czyli licznika transakcji przechowywanego w karcie.
Stąd możliwość sczytania danych do jednej transakcji w zatłoczinym autobusie ;>

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Ale odezwałeś, się, gdy napisałem, że karta powinna ujawniać tylko
jakiś jeden adres kogoś (banku/organizacji płatniczej) z kim należy
się połączyć - czyli według mnie dyskusja jest poza kontekstem
"szybko, natychmiast".

Musi być szybko. Tak czy owak, autoryzacje są coraz szybsze, więc może
jedno nie wyklucza drugiego. Autoryzacje są także potrzebne ze względu
na utracone karty itp.

Chce się mieścić i mieści się. Przynajmniej w części kart.

W stykowych, czy zbliżeniowych?

Jednych i drugich.

Spośród kart, które stosujemy (do kontroli dostępu) za najbardziej
zaawansowane uważam DesFire - ale to jest poziom AES i CMAC.
Scalaczek, który liczy ECC wymaga kilkunastu mA podczas tych obliczeń.
Nie bardzo go sobie wyobrażam w karcie _zbliżeniowej_.

Scalaki są coraz szybsze i jedzą coraz mniej prądu. Kwestia także jak
długo on to ma (może) liczyć. W każdym razie karty Paywave potrafią
robić bezstykowo kryptografię asymetryczną.

Mógłbyś wymienić wady kryptografii symetrycznej, których nie ma
asymetryczna?

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.

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

Jeśli za wadę uznać konieczność przechowywania tajnego klucza to
według mnie asymetryczna nie ma tu żadnej przewagi.

Tak normalnie, jeśli mamy dwie strony (a nie bank i bank w postaci
własnej karty, czyli praktycznie jedną stronę), to bez kryptografii
asymetrycznej nie mamy niezaprzeczalności zlecenia operacji. Ale to
niezupełnie ten przypadek.

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

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

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.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:p1h5rc$f4m$1$PiotrGalka@news.chmurka.net...

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

W dniu 2018-01-01 o 21:58, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.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.

Użytkownik "Animka"  napisał w wiadomości grup dyskusyjnych:p0lvo8$rj9$1@news.icm.edu.pl...

http://technowinki.onet.pl/hakerzy-zaatakowali-mobilne-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.