On Mon, 21 Mar 2016 14:44:40 +0100, Liwiusz
<l...@b...tego.poczta.onet.pl> wrote:
> To nie jest analogiczne.
> W karcianych chargebackach bank potrąca sobie zwracaną sumę od
> sprzedawcy, więc można uznać, że to nie bank, tylko sprzedawca
zwraca za
> transakcję, którą dokonał złodziej, albo która była przez niego źle
> zrealizowana - w obu przypadkach jest to wiadome ryzyko sprzedawcy.

Ale tematyczne orzeczenie nie dotyczy kartowego chargebacka, w tym
przypadku ( zakładając, że sprawa nie potoczy się inaczej) bank
będzie musiał zwrócić kasę poszkodowanej i założę się, że nie gdzie
to kasa odzyskana od złodzieja.

--
Marek

do góry

Marek <f...@f...com> writes:

> Zwrot transakcji nieautoryzwanych wg aktualnych przepisów nie jest z
> żadnego konta t.j. one tego nie precyzują bo nie ma takiej potrzeby,
> działa tu analogia jak w naprawie szkody. Zwrot ma dokonać bank, to
> jego problem z jakich środków to pokryje.

Rozumowanie na podobnym poziomie co "wydrukujmy sobie tyle pieniędzy, by
każdy miał ich do woli" :-(
--
Krzysztof Hałasa

do góry

Sebastian Biały <h...@p...onet.pl> writes:

> Mamy inne i raczej wirtualne doswiadczenia.

Elektroniką zajmuję się od kilkudziesięciu lat (śmiesznie to brzmi ale
formalnie jest prawdą) więc możesz traktować to, co napisałem, jako
niewirtualne.

> Ale token nie przekracza
> poziomem komplikacji zabawkę chińską grającą melodyjki za $0.5. Nie
> bardzo widzę powód dla którego mialo by to być specjalnie lepiej
> wykonane niż chiński szit. Ostatecznie dla jakiś debili w garniturach
> przygotuje się wersję pakowaną w szczotkowane aluminium z identycznym
> wsadem.
>
> Kto mówi o klawiaturze ekranowej? To zwykła pojemnosciowa już nie
> wystarczy? Kosz produkcji oscyluje w okolicy $0 bo jest częścią
> obudowy. Jest wieczna bo nie zawiera mechaniki.

W sensie "sensora" z jakimś FETem (zabezpieczonym diodami) na wejściu,
tak jak to kiedyś było robione w sprzęcie np. RTV?
Niepopularne i mało pewne rozwiązanie. Gumowa klawiatura rezystancyjna
kosztuje poniżej dolara i (dobrze zrobiona, z uszczelnieniami) jest dużo
lepsza (chociaż nie idealna).

Ale klawiatura to drobiazg. Potrzebny jest ekran, który wyświetli
informacje nt. zlecanego właśnie np. przelewu, oraz kanał, którym token
dowie się co ma wyświetlić. To ostatnie można zrobić np. przez USB -
taniej, ale wprowadzając poważne ograniczenia w funkcjonalności (np.
nie będzie działać tam, gdzie nie ma dostępu do USB, albo gdzie nie ma
właściwego sterownika itp). Lepszym rozwiązaniem jest kamera, która
obserwuje obraz wyświetlony na ekranie (typowo kod QR).

Nie można tego pominąć, jeśli chcemy, by to było bezpieczne.

W sumie, potrzebujesz:
- ekranu do wyświetlenia informacji, w dzisiejszych czas pewnie jakiegoś
IPS 320x200 3" MIPI (może SPI?)
- kamery, pewnie jakieś 640x480, MIPI albo USB, cała kamera wielkości
np. 3mm x 3mm.
- w celu zmniejszenia wielkości użyłbym jednak ekranu dotykowego, może
być rezystancyjny
- no i musi tym sterować procesor, do którego podepniesz te peryferia.
- bateria itd.

> Skąd się wzieło $15
> przy produkcji idacej w milionach sztuk?

Taka skala produkcji (w kontekście konkretnej serii konkretnego
producenta) jest mało realna, ale też niepotrzebna, bo przy o rząd
wielkości mniejszych seriach koszty są praktycznie identyczne.

Opowieści jak to można zrobić za $0.5 można między banki włożyć.

Przy czym akurat dla mnie cena $15 nie jest żadnym problemem. Ale
domyślam się, że dla banku to zbyt drogo (pomijając klientów firmowych
itp).
--
Krzysztof Hałasa

do góry

Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:

> Jesteś fanatykiem. Nie znam TPMów, nie będę się wypowiadał. Jest to
> jednak zwykły kawałek krzemu realizujący jakieś funkcje
> kryptograficzne pewnie podobne do np. HSMów albo SGXa i owszem,
> zwiększają one bezpieczeństwo ale o ile ich model matematyczny może
> wyglądać bardzo fajnie to zawsze są pewne słabości albo od takich
> trywialnych że wpinasz się kabelkami pomiędzy scalak a ściezki na
> płycie i wyciągasz wrażliwe informacje.

To inna klasa ataku, wymaga dostępu fizycznego, a na to w praktyce nie
ma żadnej rady, przynajmniej w kontekście dostępu do banków przez
Internet.

Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Dlatego potrzebne jest oddzielne, bezpieczne urządzenie. Pecet, telefon,
tablet - nie są w tym sensie bezpieczne.

Takie urządzenia są zresztą wykorzystywane (np. do innych zastosowań),
tyle że cena dla end usera (z cłami, VATami, i pocałowaniem w d) to
np. $100 albo inne E500.
--
Krzysztof Hałasa

do góry

Sebastian Biały <h...@p...onet.pl> writes:

>> Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?
>
> Popularnością malware z powodu popularności OSa. Jest zdecydownie
> popularnieszy niż cała reszta w kupie.

Bez znaczenia, ważna jest możliwość uruchamiania softu przez usera, oraz
stopień komplikacji systemu.

> A po ch... Zasadą działania TPM jest to że może pracować w kompie z
> milionem wirusów, trojanów, malware. I nic. Dalej jest trusted i
> pozwala na bezpieczne przeprowadzanie operacji.

Sam TPM jest wtedy może "trusted" :-), ale to zbyt wiele nie daje.

TPM może jest fajny w warunkach firmowych, gdy chcesz uniemożliwić pani
Kasi grzebanie w Windows.
--
Krzysztof Hałasa

do góry

Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:

> "Bank wysyła urządzenie do klienta z już wygenerowanym kluczem
> prywatnym (którego nigdy nie opuszcza scalaka), sobie zostawia
> publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez
> klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo,
> że żaden malware nie prosi o podpis."
>
> To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie
> podałeś lepszego.

Nie jest najlepszy, bo zawsze można wtedy bankowi zarzucić, że sam sobie
podpisał zlecenie. Jeśli już się w ogóle bawimy w kryptografię
asymetryczną, to klucz prywatny powinien być generowany w tokenie,
a bank dostawałby tylko część publiczną, w obecności klienta.

Ale to trudniejsze w użyciu niż wersja z challenge & response.
--
Krzysztof Hałasa

do góry

Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:

> Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly
> filmik jest o tym jak gościu się onanizuje skrobaniem tego TPMa i
> jechaniem po jego producentach jak po łysych psach. W okolicy 15:55
> jeśli dobrze słyszę dorzuca jeszcze coś o gościach którzy shackowali
> Nagravision, całkiem zdaje się jak na swoje czasy przyzwoity DRM
> naszego ziomala Kudelskiego. Ale nie ważne, powiedzmy, że to wszystko
> dotyczy starych chipów i że te nowe są już dobre i bezpieczne.

To nieważne, ale dlatego, że w praktyce wymaga fizycznego dostępu,
oraz dlatego, że łamanie TPMa byłoby tu niezbyt przydatne.
--
Krzysztof Hałasa

do góry

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

> Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:
>
>> "Bank wysyła urządzenie do klienta z już wygenerowanym kluczem
>> prywatnym (którego nigdy nie opuszcza scalaka), sobie zostawia
>> publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez
>> klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo,
>> że żaden malware nie prosi o podpis."
>>
>> To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie
>> podałeś lepszego.
>
> Nie jest najlepszy, bo zawsze można wtedy bankowi zarzucić, że sam sobie
> podpisał zlecenie. Jeśli już się w ogóle bawimy w kryptografię
> asymetryczną, to klucz prywatny powinien być generowany w tokenie,
> a bank dostawałby tylko część publiczną, w obecności klienta.
>
> Ale to trudniejsze w użyciu niż wersja z challenge & response.

Zakładamy, że transakcja została podpisana kluczem z TPMa, który go nie
opuścił, więc tak czy inaczej musiałby ją podpisać użytkownik jedynie na
podstawie tego co wyświetla mu aplikacja (też podpisana). Wówczas
teoretycznie można zweryfikować czy taka aplikacja mogła wyświetlić
userowi coś innego a co innego podpisać. Może jeszcze coś przeoczyłem. To
oczywiście nie jest takie proste ale to najlepszy scenarusz który w danej
chwili przyszedł mi do głowy i (zwróć uwagę) to w dodatku nie jako
kandydadat do wdrożenia tylko punkt wyścia do mojej uwagi że sam TPM nie
jest rozwiązaniem problemu nieautoryzowanych transakcji. Problem w tym, że
mój przedpiśca mnie wyśmiał, a sam poza zapodaniem hasła TPM nic lepszego
w sumie nie zaproponował.

do góry

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

> Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:
>
>> Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly
>> filmik jest o tym jak gościu się onanizuje skrobaniem tego TPMa i
>> jechaniem po jego producentach jak po łysych psach. W okolicy 15:55
>> jeśli dobrze słyszę dorzuca jeszcze coś o gościach którzy shackowali
>> Nagravision, całkiem zdaje się jak na swoje czasy przyzwoity DRM
>> naszego ziomala Kudelskiego. Ale nie ważne, powiedzmy, że to wszystko
>> dotyczy starych chipów i że te nowe są już dobre i bezpieczne.
>
> To nieważne, ale dlatego, że w praktyce wymaga fizycznego dostępu,
> oraz dlatego, że łamanie TPMa byłoby tu niezbyt przydatne.

Owszem, ale ja nie podważałem przydatności TPMa tylko "absolutnej
pewności" jaką on daje. A fizycznego dostępu nie można wykluczyć. A więc
jest możliwy (bardzo trudny do zrealizowania, ale mówimy o "absolutnej
pewności") scenariusz, że ten klucz zostanie wyskrobany a transakcja
przeprowadzona w momencie gdy użytkownik jest w posiadaniu tokena.

do góry

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

> Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:
>
>> Jesteś fanatykiem. Nie znam TPMów, nie będę się wypowiadał. Jest to
>> jednak zwykły kawałek krzemu realizujący jakieś funkcje
>> kryptograficzne pewnie podobne do np. HSMów albo SGXa i owszem,
>> zwiększają one bezpieczeństwo ale o ile ich model matematyczny może
>> wyglądać bardzo fajnie to zawsze są pewne słabości albo od takich
>> trywialnych że wpinasz się kabelkami pomiędzy scalak a ściezki na
>> płycie i wyciągasz wrażliwe informacje.
>
> To inna klasa ataku, wymaga dostępu fizycznego, a na to w praktyce nie
> ma żadnej rady, przynajmniej w kontekście dostępu do banków przez
> Internet.
>
> Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
> układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
> będzie wiele dziur (a tak właśnie jest i będzie).

Wydaje mi się, że bezpieczna eklawa Intel SGX czy ewentualnie jakaś
trustzone'a ARMa mogłaby pełnić rolę takiego urządzenia. Tylko taka
bezpiecznie sprovisionowana aplikacja miałaby możliwość łączenia się z
bankiem, a dodatkowo transakcja musiałaby być podpisana tokenem. Ale
przyznam, że jakoś szczególnie nie myślałem nad tym, więc mogę być w
błędzie.

do góry