chciałbym upewnić się, że nie ma innych możliwości niż te wskazane przeze
mnie poniżej (w sensie "tak to się właśnie robi").

scenariusz: strona uruchomiona w przeglądarce, w której użytkownik cośtam w
formanty html sobie powpisywał. skądinąd użytkownik ma w systemie
(przeglądarce) zainstalowany certyfikat do podpisu elektronicznego i
nieistotne jest skąd ma ten certyfikat ani czy jest on kwalifikowany.

tak czy siak, z poziomu kodu uruchamianego w przeglądarce muszę przeczytać
dane formularza, użyć jakiegoś api do podpisania ich (co zrobię z wynikiem
podpisywania to też jest nieistotne).

rozważam następujące możliwości.

1. istnieje jakieś API wbudowane w przeglądarki, które umożliwia na
wykonanie operacji kryptograficznej z poziomu javascript (taki
XmlHttpRequest tylko do podpisywania). ponieważ nigdy o czymś takim nie
słyszałem, zakładam że nic takiego nie ma. niemniej gdyby było to możliwe,
to byłaby rewelacja, bo nie wymagałbym niczego specjalnego po stronie
klienta.

2. napisanie apletu java (i podpisanie go moim certyfikatem), który użyje
api kryptograficznego javy. to rozwiązanie jest absolutnie realne, jednak
wymaga jre po stronie klienta.

3. napisanie kawałka activex (i podpisanie go moim certyfikatem), który
użyje ms crypto api. to rozwiazanie również jest absolutnie realne, jednak
wymaga windowsa.

4. napisanie kawałka kodu we flasu / action script, który użyje jakiegoś api
kryptograficznego dostępnego z poziomu osadzonego w stronie swfa. nie wiem
czy coś takiego istnieje, ale byłoby również ciekawe, bo wyobrażam sobie, że
wymagałoby wyłącznie plugina flashowego, a to ograniczenie jest najmniej
dotkliwe w porównaniu z ograniczeniami p.2 i p.3.

5. ?? [coś innego o czym nie wiem]

oczywiście mogę kupić gotowe komponenty, tyle że te które znam wpadają w p.2
albo w p.3 i dlatego też najpierw próbuję temat rozeznać nieco szerzej (poza
tym sam też potrafiłbym taki komponent sobie napisać, ostatecznie też kupię
już gotowy).

z góry dzięki za konstruktywne uwagi w temacie,
pozdrawiam
Wiktor Zychla

ps. chciałbym o ile to możliwe uniknąć dyskusji poza tematem czyli "a
dlaczego nie aplikacją desktopową", "a po co ten podpis" itd. interesuje
mnie wyłącznie warstwa technologiczna : przeglądarka + podpis elektroniczny.

do góry

Użytkownik "Wiktor Zychla" <>
> 1. istnieje jakieś API wbudowane w przeglądarki, które umożliwia na
> wykonanie operacji kryptograficznej z poziomu javascript (taki
> XmlHttpRequest tylko do podpisywania). ponieważ nigdy o czymś takim nie
> słyszałem, zakładam że nic takiego nie ma. niemniej gdyby było to możliwe,
> to byłaby rewelacja, bo nie wymagałbym niczego specjalnego po stronie
> klienta.
>

jesli api to activxy co jest do niczego ze wzgledow uzaleznienia od szajsu,
albo java gdzie wszystko bedziesz musial zrobic reczenie ;)

Rf

do góry

On Wed, 21 Jan 2009 10:45:24 -0000, Wiktor Zychla <u...@n...com.eu> wrote:

> chciałbym upewnić się, że nie ma innych możliwości niż te wskazane
> przeze mnie poniżej (w sensie "tak to się właśnie robi").
>
> scenariusz: strona uruchomiona w przeglądarce, w której użytkownik
> cośtam w formanty html sobie powpisywał. skądinąd użytkownik ma w
> systemie (przeglądarce) zainstalowany certyfikat do podpisu
> elektronicznego i nieistotne jest skąd ma ten certyfikat ani czy jest on
> kwalifikowany.

Po pierwsze *musisz* użyć SSL (https). Nie da się tego zastąpić żadnymi JSami,
Flashami, ani Javą/ActiveX o ile nie wyedukujesz użytkowników, że muszą koniecznie
weryfikować certyfikaty Javy/AX.

Bez https można przeprowadzić atak MITM i zanim strona dotrze do twoich użytkowników,
całkowicie usunąć z niej wszelką kryptografię albo dodać skrypty, które wysyłają
atakującemu niezaszyfrowaną kopię, podmieniają dane przed podpisaniem, etc.

Jeśli chesz uwierzytelnianie klientów za pomocą certyfikatów, to SSL w obecnych
przeglądarkach to obsługuje standardowo. Nawet możesz wygenerować i zainstalować nowy
certyfikat u klientów tagiem <keygen>:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/
attachments/20080714/07ea5534/attachment.txt

myopenid.net używa tego w praktyce.

--
this.author = new Geek("porneL");

do góry

> myopenid.net używa tego w praktyce.
>


On nie potrzebuje PKI, bo przy pomocy PKI na serwerze nie podpisze
dokumentu.... bo po drugiej strony nie ma dostepnego klucz prywatnego...
mimo ze uzytkownik wykorzystal do lokowania PKI...

Rf

do góry

On Wed, 21 Jan 2009 12:19:38 -0000, Rafal(sxat) <g...@o...pl.usunto> wrote:

> On nie potrzebuje PKI, bo przy pomocy PKI na serwerze nie podpisze
> dokumentu.... bo po drugiej strony nie ma dostepnego klucz prywatnego...
> mimo ze uzytkownik wykorzystal do lokowania PKI...

Disclaimer: nie jestem ekspertem w tej dziedzinie.

To, co miałem na myśli to:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#Cl
ient-authenticated_TLS_handshake

czyli klucz prywatny jest też po stronie klienta i serwer jest go w stanie
zweryfikować. Dzięki temu jest pewność od kogo serwer dostaje dane, z danymi
formularzy i wgranymi plikami włącznie.

Jeśli potrzeba podpisane dane przekazać dalej albo składować razem z podpisem, to
oczywiście sam SSL nie wystarczy (ale i tak trzeba go użyć, żeby ktoś postronny nie
mógł wstrzyknąć swoich danych do podpisania).

--
this.author = new Geek("porneL");

do góry

On 21.01.2009, porneL <n...@p...net> wrote:
> On Wed, 21 Jan 2009 10:45:24 -0000, Wiktor Zychla <u...@n...com.eu> wrote:
>
>> chciałbym upewnić się, że nie ma innych możliwości niż te wskazane
>> przeze mnie poniżej (w sensie "tak to się właśnie robi").
>>
>> scenariusz: strona uruchomiona w przeglądarce, w której użytkownik
>> cośtam w formanty html sobie powpisywał. skądinąd użytkownik ma w
>> systemie (przeglądarce) zainstalowany certyfikat do podpisu
>> elektronicznego i nieistotne jest skąd ma ten certyfikat ani czy jest on
>> kwalifikowany.
>
> Po pierwsze *musisz* użyć SSL (https). Nie da się tego zastąpić żadnymi JSami,
Flashami, ani Javą/ActiveX o ile nie wyedukujesz użytkowników, że muszą koniecznie
weryfikować certyfikaty Javy/AX.

I mówi to nie-ekspert (<o...@a...local>).

> Bez https można przeprowadzić atak MITM i zanim strona dotrze do twoich
użytkowników, całkowicie usunąć z niej wszelką kryptografię albo dodać skrypty, które
wysyłają atakującemu niezaszyfrowaną kopię, podmieniają dane przed podpisaniem, etc.

I co to da, jeśli serwer oczekuje podpisanych danych albo wręcz samego
podpisu i weryfikuje czy dostał co trzeba? A jeśli dane nie są wrażliwe
na ujawnienie i mogą iść bez SSL (bo jeśli by były wrażliwe, to SSL tak
czy siak by był zaprzęgnięty dla szyfrowania transmisji), to jaką
wartość będzie miało niepotrzebne zabezpieczenie szyfrowaniem?

> Jeśli chesz uwierzytelnianie klientów za pomocą certyfikatów, to SSL w obecnych
przeglądarkach to obsługuje standardowo.

Skąd pomysł że Wiktor potrzebuje uwierzytelniać klienta? Jak Wiktora
znam, to przemyślał sprawę i jeśli potrzebny mu podpis cyfrowy, to
certyfikat kliencki dla SSL *nie wystarczy* i *musi być* podpis cyfrowy.


A tak na marginesie, łamałbyś wiersze przy jakiejś przyzwoitej długości,
na przykład 72 znaków.

--
Secunia non olet.
Stanislaw Klekot

do góry

> czyli klucz prywatny jest też po stronie klienta i serwer jest go w stanie
zweryfikować. Dzięki temu jest pewność od kogo serwer dostaje dane, z danymi
formularzy i wgranymi plikami włącznie.
>
> Jeśli potrzeba podpisane dane przekazać dalej albo składować razem z
podpisem, to oczywiście sam SSL nie wystarczy (ale i tak trzeba go użyć,
żeby ktoś postronny nie mógł wstrzyknąć swoich danych do podpisania).
>

tak serwer weryfikuje podpis klucza publicznego (certyfikat klienta) na
podstawie certyfikatu root, klucz prywatny nie opuszcza komputera na ktorym
sie znajduje... i nie ma mozliwosci wygenerowania podpisu cyfrowego kluczem
klienta po stronie serwera...

Rf











---
http://www.sxar.pl/ usługi informatyczne

do góry

On Wed, 21 Jan 2009 13:04:13 -0000, Stachu 'Dozzie' K.
<d...@d...im.pwr.wroc.pl.nospam> wrote:

>> Bez https można przeprowadzić atak MITM i zanim strona dotrze do twoich
>> użytkowników, całkowicie usunąć z niej wszelką kryptografię albo dodać
>> skrypty, które wysyłają atakującemu niezaszyfrowaną kopię, podmieniają
>> dane przed podpisaniem, etc.
>
> I co to da, jeśli serwer oczekuje podpisanych danych albo wręcz samego
> podpisu i weryfikuje czy dostał co trzeba?
> A jeśli dane nie są wrażliwe
> na ujawnienie i mogą iść bez SSL (bo jeśli by były wrażliwe, to SSL tak
> czy siak by był zaprzęgnięty dla szyfrowania transmisji), to jaką
> wartość będzie miało niepotrzebne zabezpieczenie szyfrowaniem?

Nie szyfrowaniem, a sprawdzeniem, że strona przyszła z oczekiwanego źródła bez
modyfikacji.

Inaczej da się do strony idącej po http-bez-s doczepić kawałek Javascript, który
zmodyfikuje stronę tak, żeby applet/activex podpisujący dane nie widział prawdziwych
danych z formularza, a ich przetworzoną wersję. Wtedy można wrobić ofiarę w
podpisanie czegokolwiek.

Oczywiście nie będzie problemu, jeżeli applet będzie sam się pytał o dane (bez
polegania na stronie http), applet będzie podpisany i użytkownik sprawdzi kto go
podpisał.

> A tak na marginesie, łamałbyś wiersze przy jakiejś przyzwoitej długości,
> na przykład 72 znaków.

Faktycznie - sorry (bug czytnika).

--
this.author = new Geek("porneL");

do góry

> To, co miałem na myśli to:
> http://en.wikipedia.org/wiki/Secure_Sockets_Layer#Cl
ient-authenticated_TLS_handshake
>
> czyli klucz prywatny jest też po stronie klienta i serwer jest go w stanie
> zweryfikować. Dzięki temu jest pewność od kogo serwer dostaje dane, z
> danymi formularzy i wgranymi plikami włącznie.
>

o zabezpieczeniu kanału komunikacji certyfikatem też myślę, ale jako o
uzupełnieniu podpisania danych jako takich.

niestety, jeśli ktoś wymaga podpisywania DANYCH, to nie da się nabrać na
zabezpieczenie kanału komunikacji jako jedynego mechanizmu podpisywania.

Wiktor Zychla

do góry

> Inaczej da się do strony idącej po http-bez-s doczepić kawałek Javascript,
który zmodyfikuje stronę tak, żeby applet/activex podpisujący dane nie
widział prawdziwych danych z formularza, a ich przetworzoną wersję. Wtedy
można wrobić ofiarę w podpisanie czegokolwiek.
>


jesli uzytkownik nie bedzie wiedzial nic o krytoptografi uzywanej na
stronach www jak to dziala, to nie ma zadnego problemu oszukac nawet i https
:) wystarczy przejac sesje, a uzytkownik i tak odpowie twierdzaco na
wszelkie komunikaty przegladarki... :)

Rf

do góry