Vizvary II Istvan wrote:

>> To jest odpowiedz na kolejny post. Coś TPI nie chce mi przyjąć odpowiedz
>> na crosspost. Nie mam czasu, by dochodzić niuanse serwera tpi,
>> więc próbuję tą droga.

Prawdopodobnie TPI w ogóle nie obsługuje tej moderowanej grupy
dyskusyjnej.

>>> A swoją drogą, zauważyłem, że boom zainteresowanie technologią
>>> JavaCard był jakieś 2 lata temu - czy ta technologia czasami nie
>>> wymiera? A może po prostu już nie jest reklamowana, bo toczy się
>>> już własnym pędem (efekt domina)?
>>
>>
>> Tak jest. W zasadzie jest to najbardziej dynamiczny segment rynku
>> SC. w 2001 56% wzrostu (ponad 110 mln kart) mimo spadku na GSM o
>> jakies 11% (chociaż nie wiem ile kart GSM było w technologii Java

Czy możesz podać źródło tych informacji? Przydało by mi się do
opracowania które piszę. Z GSM'em to ciekawa sprawa - niedawno widziałem
promocję na stronach Plusa, oferującą komórki z takimi kartami, tylko że
ich ceny są HORENDALNE.

>>> Z tego co obserwowałem na różnych witrynach internetowych
>>> producentów kart i czytników, to JavaCard jest nadal
>>> supportowana. Tylko nie mogę do końca dojść jak się ma JavaCard
>>> do OpenFramework. Czy to jest to samo?
>>
>>
>> JacaCard to specyfikacja karty wedle Sun. Obecnie karty są
>> dostepne wedle specyfikacji 2.1.2, zapowiadana jest specyfikacja
>> 2.2. Karty wedle 2.1.2 istnieja w wersji kompatybilnej z
>> OpenPlatform (obecnie Global Platform) VISA.

Czyli niezgodne z OP VISA też istnieją?

>> OpenCard Framework to z kolei grupa robocza, która pracuje
>> (pracowała?) nad standardem komunikacji PC-karta w postaci
>> rozbudowanych klas Java. Powstała z inicjatywy Sun i IBM rok po
>> tym, jak razem z MS utworzyły wspólną grupę robocza PC/SC.
>> OpenCard Framework jesienia ubiegłego roku zakończyła działalność
>> (niczym). Podejrzewam, że dlatego, że działała i tak tylko na
>> platformie Microsoftu.

Czyli rozumiem, że:
1. nie istnieje już wspólna grupa Sun, IBM i MS, która zajmujmowała się
standardem PC/SC a OCF jest już historią.
2. VISA dalej utrzymuje swoją wersję OCF, z którą jest kompatybilna
_część_ kart JSC w specyfikacji 2.1.2
3. Istnieje część kart zgodnych _tylko_ ze specyfikacją 2.1.2, która to
specyfikacja zostanie zastąpiona wersją 2.2 i prawdopodobnie znów tylko
część będzie kompatybilna z OCF VISA.

Czy dobrze kombinuję?

>> Jest API w karcie i możesz w PC robic dowolna rzecz z karta więc
>> taka komunikacja jest mozliwa. Ale bezpieczny kanał miedzy czym a
>> czym? Między aplikacja w stacji lokalnej a kartą ?

Oczywiście choidzi o lokalny kanał komunikacji kanał.

>> Ja bym inaczej ujął, bardziej ogólnie. Inteligencja kart zapewnia
>> różne mozliwości, by wyeliminować niektóre grożne w skutkach
>> mankamenty obecnych rozwiązań. Tyle, że jesli zakładamy, że znowu
>> wygoda bedzie wazniejsza niż bezpieczeństwo, to za chwilę wróci
>> stare.

Trudno się nie zgodzić. W ogóle trudno sobie wyobrazić, żeby
pospólstwo w ogóle było w stanie podejmować racjonalne decyzje,
której technologii używać. Spodziewam się, że wygodniejsze
technologie (a za razem mniej bezpieczne) będą do tego tańsze. Wyprą
więc z rynku rozwiązania bezpieczniejsze, ale mniej wygodne i do
tego droższe... I nie ma prostego rozwiązania problemu - bo chcąc
rozpowszechnić technologię i przekonać ludzi do rozwiązań niestety
trzeba iść na ustępstwa w łatwości użytkowania rozwiązań.
Alternatywą byłoby narzucenie przez państwo rozwiązań
bezpieczniejszych, ale prawdopodobnie w ogóle niezrozumiałych dla
przeciętnego śmiertelnika.

>>>> patrz wymienianie się przez dwóch prezydentów KARTAMI !!!! po
podpisaniu
>>>> w miejscu publicznym jakiegoś tam aktu).
>>>
>>>
>>> Hę? To ma niby być gest _zamiast_ wymieniania się teczkami?!?
>>
>>
>> Nie. Tak jak sie kiedys piórami sie wymieniali.

Nie, to dla mnie za skomplikowane. Tam gdzie kończy się rozum, tam
zaczyna się polityka.

>> nie zmieniają ani nawet nie śledzą danych, które przez nich
>> przechodzą.

Tak, wiem.

>> Certyfikacja więc powinno ograniczyć się do tego, by stwierdzić że
>> dany czytnik na prawdę nic nie robi. Podejrzewam, że przepisy
zaprzestana
>> na oświadczeniu producenta lub importera. (Akurat my jestesmy w takiej
>> komfortowej sytuacji, że możemy udostepnić żródła i driverów i
>> mikrokontrolera czytnika, a mimo tego uważam za bezsensowne
>> certyfikacje czytników z przyczyn które uprzednio wymieniłem).

Chyba troche przeholowałem z tym przykładem. Prawdopodobnie
ustawodawcy chodziło o cały procesz podpisywania a w szczególności
NOŚNIKI kluczy kryptograficznych.

>>> Ci kochani prawnicy... ogólnie myślę, że można by przyjąć dość
>>> szeroką definicję dokumentu - jako DANYCH (w odróżnieniu od
>>> PROGRAMU).
>>
>>
>> A ja mysle , że sprawa nie jest taka jednoznaczna. Program tez
>> mozna podpisać (nawet wypada czasami). Czy przestał byc programem
>> ?


Masz rację. Zapomniałem o zapewnianiu autentyczności i niezmienionej
postaci programu.

>> Czy jednak wtedy, gdy dany system ma działac w oparciu o ustawy o
>> podpisie cyfrowym, nie należałoby przynajmniej zastrzec, że dane
>> podpisane musz a mieć jednoznaczą wizualna postać, która ma byc
>> zaprezentowana przed podpisaniem?

Chyba jednak tak - dane moga byc tak zaszyfrowane, ze mozna z nich
przy odpowiednim kluczu wyluskac DOWOLNA wiadomosc.

> A tak na prawde mnie to wszysko nie przekonuje. Dla mnie ważne byłoby
> przede wszystkim by podpisane cyfrowo dokumenty można było PO podpisaniu
> ale przed wysłaniem archiwizować i zweryfikować własnymi narzędziami
> (niezaleznych producentów) , więc by i dokument i podpis były
> generowane w sposób standardowy.

Nie widzę problemu, żeby aplikacja do podpisu mogla tez weryfikowac
podpisany dokument. W gruncie rzeczy wystarczy miec dwa rozne programy,
zeby byc prawie pewnym, ze dokument zostal prawidlowo podpisany.

--
Greetings, -- mailto:m...@p...fm --
Marcin Cenkier "Let's assume that there's only one truth."

do góry

In pl.comp.security Marcin Cenkier <m...@p...fm> wrote:
>
> Vizvary II Istvan wrote:
> >> Oki. Odrobi?em zadanie domowe - do karty mo?na _tak?e_ si?
> >> po??czy? kodowanym kana?em transmisyjnym w trybie exclusive.
> [...]
> > Opieranie bezpiecze?stwa na tym raczej bedzie zawodne (trojan po
> > zako?czeniu operacji dokonanej w trybie wy?acznym i zwolnieniu
> > karty przez aplikacje) tez sobie zarezerwuje kart? w trybie
> > dowolnym.
>
> W jaki to niby spos?b? Abstrachuj? od podsluchiwania klawiatury (bo tego
> sie nie da na razie unikna?) - podczas ustanowienia bezpiecznego i

Da sie - w sumie dosc latwo (nie sledzilem watku - ale rozumiem, ze
chodzi o karty chipowe a nie moduly kryptograficzne?). Po prostu czytnik
podlacza sie miedzy klawiature a komputer - PIN nawet 'nie dochodzi' do komputera.

--
Artur Karazniewicz
IT Departament/UNIX Cetelem Expansion Polska S.A.
Jagiellonska 36 st., 00-897 Warsaw, Poland
phone: +48 (22) 5118610, e-mail: k...@c...pl

do góry

"Marcin Cenkier" <m...@p...fm> wrote in message
news:3CF18146.80907@poczta.fm...
> Vizvary II Istvan wrote:
>

Tamte informacje o dynamice JAVA Card pochodzą z
http://www1.slb.com/smartcards/news/02/sct_trends180
3.html
Póki chodzi o przeszłość to im wierze. W końcu maja informację z pierwszej
reki. Inna sprawa jest progrnoza.

> >> JacaCard to specyfikacja karty wedle Sun. Obecnie karty są
> >> dostepne wedle specyfikacji 2.1.2, zapowiadana jest specyfikacja
> >> 2.2. Karty wedle 2.1.2 istnieja w wersji kompatybilnej z
> >> OpenPlatform (obecnie Global Platform) VISA.
>
> Czyli niezgodne z OP VISA też istnieją?

Ależ oczywiście. Na przykład karty GSM zgodne z JAVA, nie majace nic
wspólnego z Open Platform. Najbardziej rzucajaca się w oczy róznica jest
taka, że wersja zgodna z Open Platform w ogóle nie przewiduje dosep do
danych
w sposób inny niz przez aplety, za to karty GSM z Java ze względu na
wymagana
kompatybilność ze standardem GSM 11.14 oczywiscie taki dostep zapewniaja.

> Czyli rozumiem, że:
> 1. nie istnieje już wspólna grupa Sun, IBM i MS, która zajmujmowała się
> standardem PC/SC a OCF jest już historią.
> 2. VISA dalej utrzymuje swoją wersję OCF, z którą jest kompatybilna
> _część_ kart JSC w specyfikacji 2.1.2
> 3. Istnieje część kart zgodnych _tylko_ ze specyfikacją 2.1.2, która to
> specyfikacja zostanie zastąpiona wersją 2.2 i prawdopodobnie znów tylko
> część będzie kompatybilna z OCF VISA.
>
> Czy dobrze kombinuję?

Dokładniej MS, Sun i IBM w 1997 utworzyły PCSC worgkroup razem z
producentami
kart. (http://www.pcscworkgroup.com/) Rok pózniej powstała konkurencyjna
OpenCard Framework ( http://www.opencard.org/ ) inicjatywa odrebna Sun i
IBM.
Jednocześnie Sun i IBM wystapiły z PCSC Workgroup. Standardy te dotyczą
komunikację
cztnik (karta) - PC. Również model realizacji sprzętowego wspomagania
kryptografii w PC.

Java Card to zupełnie inna sprawa. Wcale nie musi być obsługiwana
narzędziami z OCF.
Istnieje bowiem pewne "wąskie gardło" w postaci rozkazów wysłanych do karty
i odebranych
z karty. Nawet jeśli zdefiniujesz to jako rozbudowaną klasę JAVA, to w końcu
efektem jest
wysłanie kilku bajtów do karty, które możesz wysłać w jakikolwiek sposób.
Nawet wystukując z terminala w sposób szestnastkowy. Efekt bedzie ten sam.

>Spodziewam się, że wygodniejsze
> technologie (a za razem mniej bezpieczne) będą do tego tańsze. Wyprą
> więc z rynku rozwiązania bezpieczniejsze, ale mniej wygodne i do
> tego droższe... I nie ma prostego rozwiązania problemu - bo chcąc
> rozpowszechnić technologię i przekonać ludzi do rozwiązań niestety
> trzeba iść na ustępstwa w łatwości użytkowania rozwiązań.
> Alternatywą byłoby narzucenie przez państwo rozwiązań
> bezpieczniejszych, ale prawdopodobnie w ogóle niezrozumiałych dla
> przeciętnego śmiertelnika.

Jeszcze inaczej jest.
Dochodzi bowiem do tego
walka wielkich producentów,
zjawisko dosyc niewygodne dla Amerykanów, mianowicie fakt, że masowe
podpisywanie danych to przy okazji masowe ich szyfrowanie - więc brak
mozliwości śledzenia w czasie rzeczywistym ruchu w Internecie.
Dodaj do tego narcyzm srodowisk opiniotworczych (ze tak po prostu kazdy
bedzie podpisywal i szyfrowal?) i
brak przyjaznego sposobu przekazywania informacji o zastosowanych metodach
(patrzcie no Panstwo jaki to ja jestem mądry ...) Efekt taki, że gdy ludzie
usłyszą słowo "matematyka" to natychmiast przestaną słuchać. To samo dotyczy
dziennikarzy, którzy jak juz cokolwiek pojęli (lub im się wydaje że pojęli)
ze
szczegółów technicznych (zresztą często zupełnie niepotrzebnie) to zamiast
starać
sie wytłumaczyć w sposób przystepny po co to jest, co to daje i na czym to
polega,
zaczynają się popisywać jakimś absolutnie hermetycznym językiem, często
myląc
zresztą pojęcia.

[...]
> > A tak na prawde mnie to wszysko nie przekonuje. Dla mnie ważne byłoby
> > przede wszystkim by podpisane cyfrowo dokumenty można było PO
podpisaniu
> > ale przed wysłaniem archiwizować i zweryfikować własnymi narzędziami
> > (niezaleznych producentów) , więc by i dokument i podpis były
> > generowane w sposób standardowy.
>
> Nie widzę problemu, żeby aplikacja do podpisu mogla tez weryfikowac
> podpisany dokument. W gruncie rzeczy wystarczy miec dwa rozne programy,
> zeby byc prawie pewnym, ze dokument zostal prawidlowo podpisany.

Nie chodzi o to, by ta sama aplikacja lub inna aplikacja z tego samego
żródła weryfikowała postu, ale bym nazędziami niezaleznego producenta mógł
sprazwdzić co takiego podpisałem zanim decyduję wysłać w świat coś , czemu
nie mogę w przyszłości zaprzecić.


Vizvary Istvan

do góry

Dnia 24 May 2002 15:27:53 +0200, i...@p...onet.pl napisał(a):
>Jeżeli wartość funkcji skrótu oblicza aplikacja to rozwiązanie to w zakresie
>bezpieczeństwa i pewności działania różni się od rozwiązania z kartą z
>koprocesorem kryptograficznym tylko tym że jest bardziej uciążliwe.

Bynajmniej - mam do wklepania 8 cyfr na tokenie i wklepuję potem odpowiedź
do formularza... i gotowe. Nie muszę się bać, że ktoś zainstalował w
komputerze trojana który podglądnie wklepywany PIN do karty procesorowej...

>Jak ufam aplikacji to zewnętrzny token nie jest potrzebny.

Widzisz - a ja z tokenem nie muszę się bać, idąc do np. kawiarenki
internetowej...

> Jak jej nie ufam to skąd wiem co podpisuję?.

Aplikacji mogę ufać - a czy komputerowi, systemowi? To zmienić dużo
łatwiej...

Pozdrawiam,
--
Jacek Osiecki
j...@c...pl
GG: 1522172

do góry

Artur Karazniewicz wrote:
> Da sie - w sumie dosc latwo (nie sledzilem watku - ale rozumiem, ze
> chodzi o karty chipowe a nie moduly kryptograficzne?). Po prostu czytnik
> podlacza sie miedzy klawiature a komputer - PIN nawet 'nie dochodzi' do komputera.

niezle kombinujesz.... tylko czy takie rozwiazanie w ogole ktos rozwija?

--
Greetings, -- mailto:m...@p...fm --
Marcin Cenkier "Let's assume that there's only one truth."

do góry

Użytkownik "Jacek Osiecki" <j...@c...pl> napisał w wiadomości
news:slrnaf40h7.3tp.joshua@pingwin.ani...
> Dnia 24 May 2002 15:27:53 +0200, i...@p...onet.pl napisał(a):
> >Jeżeli wartość funkcji skrótu oblicza aplikacja to rozwiązanie to w
zakresie
> >bezpieczeństwa i pewności działania różni się od rozwiązania z kartą z
> >koprocesorem kryptograficznym tylko tym że jest bardziej uciążliwe.
>
> Bynajmniej - mam do wklepania 8 cyfr na tokenie i wklepuję potem odpowiedź
> do formularza... i gotowe. Nie muszę się bać, że ktoś zainstalował w
> komputerze trojana który podglądnie wklepywany PIN do karty
procesorowej...
>
> >Jak ufam aplikacji to zewnętrzny token nie jest potrzebny.
>
> Widzisz - a ja z tokenem nie muszę się bać, idąc do np. kawiarenki
> internetowej...
>
> > Jak jej nie ufam to skąd wiem co podpisuję?.
>
> Aplikacji mogę ufać - a czy komputerowi, systemowi? To zmienić dużo
> łatwiej...

Wszystko zależy do czego używasz - do podpisywania to tylko karty
procesorowe, jeśli do autentykacji to tokeny (BTW. są specjalne klawiaturki,
gdzie wkładasz kartę czipową i masz token - normalny łosz'en'goł). Co do
podpisów dochodzimy do kwestii, która w ustawie nosi nazwę bezpieczne
urządzenie. Wg ustawy urządzenie takie w cale nie musi być bezpieczne de
facto. Ma mieć certyfikat, że jest bezpieczne, a to co innego. Brak jest
ciągle odpowiednich przepisów wykonwaczych, które pozwolą na przeprowadzenie
takiej certyfikacji. Możemy się jedynie domyślać, jak to będzie wyglądać.
Rozwiązanie jest w zasadzie jedno:
urzadzenie prezentuje cały podpisywany tekst (bo podpisuje się tekst, a nie
tekst + formę) przed podpisaniem. Do tego cała operacja (czyli generacja
skrótu, podanie PIN'u, podpisanie) odbywa się na urządzeniu podpisującym,
podczas której nie odbywa się, żadna komunikacja z komputerem, do którego to
urządzenie jest podpięte.
Można domniemywać, że rozporządzenie będzie zawierać taką definicje. A to z
kilku powodów:
- jest to jedyne rzeczywiście bezpieczne rozwiązanie dla podpisującego
- cała odpowiedzialność za podpisany tekst spada na podpisującego
(niezaprzeczalność)
- odpowiedzialność za bezpieczeństwo urządzenia spada na podpisującego
(prawdopodobnie częściowo poza wyjątkami typu banki i inne instytucje
zaufania publicznego, które będą musiały udostępnić odpowiednie urządzenia
swoim klientom)
- 99% transakcji nie będzie wymagało podpisu kwalifikowanego (a więc
bezpiecznego urządzenia podpisującego)
- duża część istotnych transakcji (np. wszystkie umowy notarialne) będą
dalej musiały mieć formę tradycyjnej, papierowej umowy.

Pozdrawiam



--
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

In pl.comp.security Marcin Cenkier <m...@p...fm> wrote:

> niezle kombinujesz.... tylko czy takie rozwiazanie w ogole ktos rozwija?
>

Tak :)) z tego co widzialem sporo czytnikow 'crypto-related' ma takie
rozwiazania - przynajmniej te z ktorymi pracowalem np.
Algorithmic Research.

artur.

--
Artur Karazniewicz
IT Departament/UNIX Cetelem Expansion Polska S.A.
Jagiellonska 36 st., 00-897 Warsaw, Poland
phone: +48 (22) 5118610, e-mail: k...@c...pl

do góry

In pl.comp.security Marcin Cenkier <m...@p...fm> wrote:
>
> Artur Karazniewicz wrote:
>> Da sie - w sumie dosc latwo (nie sledzilem watku - ale rozumiem, ze
>> chodzi o karty chipowe a nie moduly kryptograficzne?). Po prostu czytnik
>> podlacza sie miedzy klawiature a komputer - PIN nawet 'nie dochodzi' do komputera.
>
> niezle kombinujesz.... tylko czy takie rozwiazanie w ogole ktos rozwija?

AHA - BTW. sa tez czytniki z PIN-apdem - to jest IMO - jeszcze lepsze
rozwiazanie...

Artur

--
Artur Karazniewicz
IT Departament/UNIX Cetelem Expansion Polska S.A.
Jagiellonska 36 st., 00-897 Warsaw, Poland
phone: +48 (22) 5118610, e-mail: k...@c...pl

do góry

Artur Karazniewicz wrote:
>>niezle kombinujesz.... tylko czy takie rozwiazanie w ogole ktos rozwija?
>
> Tak :)) z tego co widzialem sporo czytnikow 'crypto-related' ma takie
> rozwiazania - przynajmniej te z ktorymi pracowalem np.
> Algorithmic Research.

nieźle. Wlaśnie sobie pomyślałem, że przecierz istnieją klawiatury z
zintegrowane z czytnikami kart - być może one działąją na tej samej
zasadzie?

--
Greetings, -- mailto:m...@p...fm --
Marcin Cenkier "Let's assume that there's only one truth."

do góry

Artur Karazniewicz wrote:
>>niezle kombinujesz.... tylko czy takie rozwiazanie w ogole ktos rozwija?
>
> AHA - BTW. sa tez czytniki z PIN-apdem - to jest IMO - jeszcze lepsze
> rozwiazanie...

Rozmawialiśmy o czymś takim z Vizvarym, to by byla rewelacja - ciekawa
by byla także możliwość podglądu podipsywanego dokumentu na zewnętrznym
terminalu, a nie na ekranie kompa (karta by obliczała skrót). Ale
oczywiście to ma swoje ograniczenia - forma dokumentów musiałyby być
sensownie zestandaryzowana, no i wyświetlacz dość pokażny. TO dość
drogie rozwiązanie, niemarketingowe.

--
Greetings, -- mailto:m...@p...fm --
Marcin Cenkier "Let's assume that there's only one truth."

do góry