On 2016-03-26 14:39, Marek wrote:
>> Fajnie. Ciekawe dlaczego od jakiegoś czasu państwo PL promuje
> podpisy
>> elektroniczne które mozna sobie uzyskać z urzedu.
> Zapomniałeš dopisać "... i nie mają u nas powszechnego a i więc
> praktycznego zastosowania".

Jakieś tam mają. Problem w tym że ja go nie wnioskowałem bo nie mam
śladowego zaufania do procesu jego pozyskiwania z urzędu ("pan se
przyniesie pena to sie skopiuje").

do góry

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

> Ktoś mający przez chwilę dostęp do tokena jest w posiadaniu
> znajdującego się w nim klucza (w sensie: może go użyć) jeśli nie mamy
> dodatkowych zabezpieczeń które powiązują token z osobą. Jeżeli
> aplikację wgrywa bank to:
>
> - po pierwsze w dalszym ciągu można postawić mu zarzut "daliście mi token
> z kluczem i aplikacją, a teraz mówicie, że transakcja była
> uwierzytelniona bo tak wskazuje wasz system informatyczny". W przypadku
> gdy klient sam generuje klucz i wgrywa aplikację taki zarzut pod adresem
> banku już jest niemożliwy

Owszem, ale 99,xxx% klientów banku nie potrafi tego bezpiecznie zrobić.
Nie ma sensu rozważać takich sytuacji.
Po prostu należy założyć, że bank (ale niekoniecznie jego szeregowi
pracownicy) jest godny zaufania.

Alternatywą jest normalny podpis cyfrowy, ale to bardziej skomplikowane,
wymaga "przeszkolonego pracownika", i nie do zaoferowania klientowi
indywidualnemu. Zresztą w sytuacji z przeszkolonym pracownikiem to także
zwykle nie jest bezpieczne, przecież jak przyjedzie serwisant z banku to
XX % ludzi da im pełny dostęp do wszystkiego. Po prostu to są
technologie dla specyficznych części wojska albo innych agencji itp.

> - po drugie wyobrażam sobie że można wtedy dość skutecznie przeprowadzić
> od strony banku atak ukierunkowany na konkretną osobę wysyłając coś co w
> rzeczywistości bezpiecznym tokenem nie jest a klucz prywatny ma
> atakujący.

Dlatego napisałem, że programowanie tokena (inne niż
generowanie/ustawianie klucza) nie powinno być dostępne.

> Jak dyrektor banku przeczyta, że ktoś go zwyzywał na niusach
> od debili to ma pokusę aby to zrobić.

Poważnie? Może jakiś partyjny dyrektor :-)

> Jeśli w token każdy zaopatruje się
> indywidualnie i anonimowo tudzież w podobny sposób wgrywa aplikację to
> taki atak jest właściwie wykluczony.

Nie jest, każdy wie do czego służą takie tokeny i co może dać atak na
nawet niewielką część z nich. Przykład - afera w RSA Security
(i spowodowane nią włamania w Lockheedzie oraz przypuszczalnie wiele
innych, o których nie wiemy).

> Piszesz, że nie koniecznie potrzebujemy kluczy asymetrycznych. Możesz
> wyjaśnić jak to się odbywa bez takich kluczy? Wyobrażam sobiem, że
> taki sam klucz symetryczny musiałby powstać jednocześnie w tokenie
> użytkownika i infrastrukturze banku. Ale zakładając, że wogóle on nie
> powinien opuszczać chipa jest to jakieś wyzwanie technologiczne.

Bez problemu, bank może generować klucz i zapisywać go w tokenie (typowy
schemat). User także może zapisać nowy klucz (przy odrobinie wysiłku) -
token przestanie wtedy "działać" z bankiem.

> Rozumiem, że coś na kształt takiej technologii istnieje?

Tak naprawdę to nie jest nawet żadna specyficzna technologia, to tak
jakby pytać o technologię kalkulatora.

Ja osobiście nie zajmuje się projektowaniem dokładnie takich rzeczy,
ale jakbym miał coś takiego zrobić, to sprawa byłaby prosta: Cortex M4,
wyświetlacz OLED 3"+, touchscreen MT, akumulator, mała kamera. Ew. USB
jako "wyjście" (emulacja klawiatury?). Sklejona obudowa.

> Chodzi o
> provisionowanie klucza na zasadzie jakiegoś DRMa?

Rozwiniesz skrót? Żaden mi nie pasuje. Generalnie to są proste rzeczy,
aczkolwiek niewątpliwie wiele "zamkniętych" implementacji było
wadliwych. Teraz można zamówić taki sprzęt "pod klucz" w niewielkich
seriach (nie tylko w kontekście banku). Kryptograficznie wszystko składa
się ze znanych klocków - AES, SHA, RSA itd.
--
Krzysztof Hałasa

do góry

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

> Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za
> każdym razem systemu z LiveCD.

No to musisz się zdecydować - jest czy go nie ma :-)

> Tak, wiem że może się skompilować sam, ale nie kązda distro ma
> kompilator. Można tez napisać bootnet w bashu zapewne. Mozna. Tylko po
> ch...

O to musiałbyś zapytać autorów. Bo wiesz, takie rzeczy są spotykane
w naturze (w szczególności na starszych maszynach pozbawionych opieki).

Obserwowałeś kiedyś pakiety TCP SYN na jakiś publiczny port 22?
To chyba nie jest celowane w MS Windows?

> TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie.

Jest przykładem niepasującym do sytuacji.
Zabezpieczenia w samym krzemie są na tym poziomie całkowicie nieistotne,
wystarczy odpowiednia obudowa. To zupełnie nie ta klasa bezpieczeństwa.

>> W tak zmienionych warunkach rzeczywiście można to zrobić bezpiecznie,
>> co zresztą od początku pisałem. Z tym że proponuję skasować USB
>> i zastosować małą kamerę - jest to bardzo dobre rozwiązanie, sprawdzone
>> w praktyce.
>
> Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze
> rozpoznawanie głosu póki nie wynaleziono magnetofonów.
>
> http://www.computerworld.com/article/2531298/windows
-pcs/laptop-face-recognition-tech-easy-to-hack--warn
s-black-hat-researcher.html

Mam odpowiedzieć argumentem, że złącze USB da się "podrobić"?
Kamera nie służy przecież do rozpoznawania niczego oprócz kodu QR.
Może być kserokopia.

> Żeby udowodnić że trojany na linuxie się problemem w kernelu należy
> podać przykłady takich prób bądź ich istnienia.

Przecież był nawet podany przykład. Faktem jest, że zwykle trudno
udowodnić (poza takimi przypadkami), że wprowadzony przez kogoś bug jest
celowym trojanem. Aczkolwiek, jeśli exploit nieznanego publicznie
wcześniej buga systemu napisanego przez Agencję znajdujemy w sofcie
przeznaczonym dla "służb" do włamań, to różnie można to oceniać.

BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
bezpieczne, w przeciwnym przypadku nie jest takie. Ten pierwszy dowód
też często życie weryfikuje.

> Przecież ipsec to tylko jeden przykład z wielu.

Niereprezentatywny.

> Obecnie majstrowanie
> przy kryptografii jest o tyle dobre że mało jest na świecie osob ktore
> znajdą backdoor w wartwie matematycznej.

Jak nietrudno zauważyć nie jesteś osamotniony w tym poglądzie,
aczkolwiek życie pokazuje, że nie jest to takie proste.

> TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło
> do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że
> chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział
> co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank)
> + klawiatura (pewnośc że to user).

Sam widzisz: TPM ma się do tego dokładnie nijak.
--
Krzysztof Hałasa

do góry

On 2016-03-31 21:08, Krzysztof Halasa wrote:
>> Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za
>> każdym razem systemu z LiveCD.
> No to musisz się zdecydować - jest czy go nie ma :-)

Bo on jest chwilowo bezpieczny z powodu braku UEFI w BIOSie na *moim*
kompie.

> Obserwowałeś kiedyś pakiety TCP SYN na jakiś publiczny port 22?
> To chyba nie jest celowane w MS Windows?

Ojej, pakiety na 22? Straszne. Pamiętam jak adminowałem siecią osiedlową
swego czasu. Co kilkanaście minut miałem telefon że ktoś kogoś hakuje
pingiem. No, co prawda to prawda, Win98 potrafił ładnie się wycypać od
ping of death. Pakiety na 22, strasze. Lepieuj zapytaj ile było pakietów
w sieci z Blastera. Średni czas przeżycia WinXP na modemie to było 30
sekund.

>> TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie.
> Jest przykładem niepasującym do sytuacji.
> Zabezpieczenia w samym krzemie są na tym poziomie całkowicie nieistotne,
> wystarczy odpowiednia obudowa. To zupełnie nie ta klasa bezpieczeństwa.

ROTFL. No i widzisz, sensu istnienia TPM nie rozumiesz. One istnieją
dlatego że są *zabezpieczone* w krzemie na ogromną ilośc sposobów
powodując że wydłubanie sekretów jest nieosiągalne za normalne
pieniądze. To jest *sedno*. Jak widze wolisz wyrzucić sedno i gadać o
bzdurach typu podrabianie gniazdek USB. Super.

>> Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze
>> rozpoznawanie głosu póki nie wynaleziono magnetofonów.
>> http://www.computerworld.com/article/2531298/windows
-pcs/laptop-face-recognition-tech-easy-to-hack--warn
s-black-hat-researcher.html
> Mam odpowiedzieć argumentem, że złącze USB da się "podrobić"?

Podrabiaj. Nic to nie da. Mając do dyzpozycji układ podpisujący
zawierający wewnątrz klucz ktorego nie można odczytać mogę sobie
podpisywać wiarygodnie na dowolnie zawirusowanym komputerze i dowolnej
ilości przelotek usb wstawianych pomiedzy scalak a komputer. Tak
działają wszelakie "bezpieczne enklawy". Stan środowiska zewnętrznego
nie wpływa na wiarygodność czegokolwiek wewnatrz. jedyne co możesz
zsrobić to obstrukcję danych, która w sposob trywialny jest wykrywana po
drugiej stronie (bank) albo DoS.

> Kamera nie służy przecież do rozpoznawania niczego oprócz kodu QR.
> Może być kserokopia.

O to jeszcze ciekawiej. Kod można cyknąć byle iPhone z odległości kilku
metrów. I znowu security na poziomie dziadostwa, jak to zazwyczaj w
bankowości. No i jak wiadomo nie istnoeja na świecie zlośliwe aplikacje
ktore pozwalają przejąć na chwile kamerę która właśnie cyknąłeś zdjęcie.
Uff...

>> Żeby udowodnić że trojany na linuxie się problemem w kernelu należy
>> podać przykłady takich prób bądź ich istnienia.
> Przecież był nawet podany przykład. Faktem jest, że zwykle trudno
> udowodnić (poza takimi przypadkami), że wprowadzony przez kogoś bug jest
> celowym trojanem. Aczkolwiek, jeśli exploit nieznanego publicznie
> wcześniej buga systemu napisanego przez Agencję znajdujemy w sofcie
> przeznaczonym dla "służb" do włamań, to różnie można to oceniać.

Gdzie te trojany do manipulowania danymi przelewu w kernelspace się
pytam? Można sobie dowolnie bajać o tajnych słuzbach Kamboży
wciskających złośliwe trojany, ale GDZIE one są?

> BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
> bezpieczne

To niemożliwe. Podobnie jak nie da się udowodnić że OTW działa zawsze.

>, w przeciwnym przypadku nie jest takie.

Nikt tu nie mówi o 100% bezpieczeństwie, raczej o absolutnie
nieoplacalnym łamaniu zabezpieczeń.

>> TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło
>> do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że
>> chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział
>> co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank)
>> + klawiatura (pewnośc że to user).
> Sam widzisz: TPM ma się do tego dokładnie nijak.

Bo, co powtorze po raz Nty, TPM to tylko *przykład* technologii, a
najwazniejszą częscią tej technologi są zabezpieczenia w krzemie które
są *krytyczne* aby mówić o bezpieczeństwie tokenow bo czynia ich
klonowanie/oszukiwanie nieopłacalnym.

do góry

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

> Ojej, pakiety na 22? Straszne. Pamiętam jak adminowałem siecią
> osiedlową swego czasu.

Baaardzo istotne. Faktem jest, że takie ataki dotyczą (domyślam się)
zarówno Windows jak i (wiem) Linuksa.

> ROTFL. No i widzisz, sensu istnienia TPM nie rozumiesz.

Mylisz się, ja rozumiem zarówno ogólny sens, jak i działanie TPM. I nie
tylko jako "abstrakcyjny przykład technologii". Tym się różnimy.
Jest to łatwe do stwierdzenia - każdy, kto proponuje użycie TPM jako
zabezpieczenie kontaktu z bankiem, nie wie co pisze.

> O to jeszcze ciekawiej. Kod można cyknąć byle iPhone z odległości
> kilku metrów. I znowu security na poziomie dziadostwa, jak to
> zazwyczaj w bankowości.

??? Nie ma związku. Nie myślisz chyba że przechwycenie kodu QR mogłoby
do czegoś służyć? To tylko niezabezpieczony kanał komunikacyjny.

> No i jak wiadomo nie istnoeja na świecie
> zlośliwe aplikacje ktore pozwalają przejąć na chwile kamerę która
> właśnie cyknąłeś zdjęcie. Uff...

W specjalizowanym tokenie? Nawet jeśli je tam ktoś umieścił... (co jest
raczej bardzo mało prawdopodobne, za to dość łatwo byłoby znaleźć
winnego).
To co takiego zrobią te "aplikacje"? Wyświetlą brzydki rysunek?

> Gdzie te trojany do manipulowania danymi przelewu w kernelspace się
> pytam? Można sobie dowolnie bajać o tajnych słuzbach Kamboży
> wciskających złośliwe trojany, ale GDZIE one są?

Mało śmieszne.

>> BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
>> bezpieczne
>
> To niemożliwe. Podobnie jak nie da się udowodnić że OTW działa zawsze.
>
>>, w przeciwnym przypadku nie jest takie.
>
> Nikt tu nie mówi o 100% bezpieczeństwie, raczej o absolutnie
> nieoplacalnym łamaniu zabezpieczeń.

Znów musisz się zdecydować.
BTW takie dowody jednak przeprowadza się. Opierają się na pewnych
założeniach (np. na takim, że nie da się skutecznie rozłożyć odpowiednio
dużej liczby na czynniki). Opłacalność to masz w odporności karty
kablówki.

> Bo, co powtorze po raz Nty, TPM to tylko *przykład* technologii, a
> najwazniejszą częscią tej technologi są zabezpieczenia w krzemie które
> są *krytyczne* aby mówić o bezpieczeństwie tokenow bo czynia ich
> klonowanie/oszukiwanie nieopłacalnym.

Nie. Ale nie chce mi się już powtarzać tego samego, możesz sobie trwać
w tych swoich teoriach.
--
Krzysztof Hałasa

do góry