On 08/27/2011 04:50 AM, m...@t...pl wrote:
>
>> Co do założeń, to to zależy od wymagań. Klucz zahasłowany jest na tyle
>> bezpieczny, na ile bezpieczny jest komputer, na którym przebiega
>> podpisywanie.
> Łącze chyba też musi być bezpieczne. Czy są znane skuteczne metody obrony
> przed atakiem człowiek w środku? Chyba nie ma...
> Pozdrawiam
>
>

Dla dwóch komputerów: SSL.

Dla trzech, czyli klienta, serwera uwierzytelniania/dostępu
i serwera, który coś udostępnia:
Kerberos (i, ten sam mechanizm, Active Directory).
Najciekawsze jest to, że tylko klient wymienia pakiety
z pozostałymi, które między sobą się nie komunikują. Wszystko
w łączach odkrytych.

Edek

do góry

On Sat, 27 Aug 2011 13:09:22 +0200, Michal Kleczek
<k...@p...onet.pl> wrote:

>On 2011-08-27 11:57, slawek wrote:
>> Użytkownik "A.L." napisał w wiadomości grup
>> dyskusyjnych:i5if57d47lnl8cfhce680edf4hju468aso@4ax.
com...
>>
>>> DOWOLNA rzecz ma skutki prawne, nawet uzywana wewnatrz firmy, jezeli
>>> nastapi jakis wypadek, utrata mienia, itede, i pojawi sie sprawa
>>
>> 100% zgody.
>>
>> Myślę, że problem redukuje się do: "jak zrobić podpis elektroniczny ale
>> tak aby to nie był podpis elektroniczny".
>>
>> Czyli: A && ~A .
>>
>>
>
>Chyba nie do konca.
>Problem polega na tym, ze powszechnie stosowane technologie podpisu
>elektronicznego wymagaja dosyc kosztownej infrastruktury i sa niezbyt
>wygodne w uzyciu. Szczegolnie wymaganie dwuczynnikowosci (czyli "must
>know and must have") uwierzytelniania powoduje niewygode (choc zapewne
>jest b. bezpieczne). Znacznie latwiej byloby gdyby wystarczylo "must know".
>
>Jezeli ktos zna tego rodzaju rozwiazanie (czyli asymetryczne
>szyfrowanie/deszyfracja ale tylko w oparciu o haslo) - bardzo chetnie je
>poznam.
>Np cos oparte o:
>http://en.wikipedia.org/wiki/BLS_(cryptography)
>gdzie klucz prywatny jest generowany na podstawie hasla.


A PGP nei da sie uzyc?...

Using PGP to Verify Digital Signatures
www.cert.org/archive/pdf/PGPsigs_paper2.pdf

Sporo wiecej jes tw sieci na temat PGP i electronic signature

A.L.

do góry

On 2011-08-27 17:30, A.L. wrote:
> On Sat, 27 Aug 2011 13:09:22 +0200, Michal Kleczek
> <k...@p...onet.pl> wrote:
>
>> On 2011-08-27 11:57, slawek wrote:
>>> Użytkownik "A.L." napisał w wiadomości grup
>>> dyskusyjnych:i5if57d47lnl8cfhce680edf4hju468aso@4ax.
com...
>>>
>>>> DOWOLNA rzecz ma skutki prawne, nawet uzywana wewnatrz firmy, jezeli
>>>> nastapi jakis wypadek, utrata mienia, itede, i pojawi sie sprawa
>>>
>>> 100% zgody.
>>>
>>> Myślę, że problem redukuje się do: "jak zrobić podpis elektroniczny ale
>>> tak aby to nie był podpis elektroniczny".
>>>
>>> Czyli: A&& ~A .
>>>
>>>
>>
>> Chyba nie do konca.
>> Problem polega na tym, ze powszechnie stosowane technologie podpisu
>> elektronicznego wymagaja dosyc kosztownej infrastruktury i sa niezbyt
>> wygodne w uzyciu. Szczegolnie wymaganie dwuczynnikowosci (czyli "must
>> know and must have") uwierzytelniania powoduje niewygode (choc zapewne
>> jest b. bezpieczne). Znacznie latwiej byloby gdyby wystarczylo "must know".
>>
>> Jezeli ktos zna tego rodzaju rozwiazanie (czyli asymetryczne
>> szyfrowanie/deszyfracja ale tylko w oparciu o haslo) - bardzo chetnie je
>> poznam.
>> Np cos oparte o:
>> http://en.wikipedia.org/wiki/BLS_(cryptography)
>> gdzie klucz prywatny jest generowany na podstawie hasla.
>
>
> A PGP nei da sie uzyc?...

Przeciez to RSA i jako takie wymaga przechowywania kluczy na jakims nosniku.
A mnie chodzi o system, gdzie jest _tylko_ haslo.

--
Michal

do góry

> On 2011-08-27, m...@t...pl <m...@t...pl> wrote:

> Oczywiście że są znane.
To co można zrobić jak program otrzymał klucz publiczny kogoś
innego niż adresata? Coś mi się wydaje że nic i musi być bezpieczny
sposób dostarczenia klucza publicznego.
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

m...@t...pl pisze:
>> Sam system wymagał trochę pracy do jego przygotowania, ale działał
>> bardzo sprawnie.
> Jaka to była ilość pracy jeśli można spytać?
> Pozdrawiam

Przygotowanie serwera, oraz aplikacji tak by wykrywały klucz i montowały
podpis w systemie - niestety jeśli są pracownicy nieużywający na co
dzień komputera, albo używający tylko jednego programu - mogą mieć
problem, a sterowniki dostarczane z kluczami - przynajmniej wtedy nie
potrafiły tego robić z automatu. Dodatkowo - przygotowanie odpowiednio
systemu na serwerze, aby generował różnego typu dokumenty. Nic coby
przerastało jakoś średniej klasy programistów, lecz trzeba to zrobić.
Możliwe, że obecnie można kupić już podobne systemy, jak wprowadzane
było w tamtej firmie, ciężko było znaleźć cos odpowiedniego na rynku.


--
Kaczus
http://kaczus.republika.pl

do góry

On 2011-08-28 15:31, m...@t...pl wrote:
>> On 2011-08-27, m...@t...pl<m...@t...pl> wrote:
>
>> Oczywiście że są znane.
> To co można zrobić jak program otrzymał klucz publiczny kogoś
> innego niż adresata?

Podpisac klucz publiczny. To sie nazywa "certyfikacja".

> Coś mi się wydaje że nic i musi być bezpieczny
> sposób dostarczenia klucza publicznego.

Fakt. Ale nie klucza adresata, lecz klucza wystawcy certyfikatu.
No i ten bezpieczny sposob to np. zaszycie w programie instalacyjnym
systemu operacyjnego.

--
Michal

do góry

On 2011-08-28, m...@t...pl <m...@t...pl> wrote:
>> On 2011-08-27, m...@t...pl <m...@t...pl> wrote:
>
>> Oczywiście że są znane.
> To co można zrobić jak program otrzymał klucz publiczny kogoś
> innego niż adresata? Coś mi się wydaje że nic i musi być bezpieczny
> sposób dostarczenia klucza publicznego.

O, nie, nie, mój drogi. Nie zmieniaj reguł dyskusji w trakcie jej
trwania. Nie było mowy o ataku na przekazywanie klucza publicznego,
tylko na ataki MitM w ogóle.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dzizas, chłopaki, ale kombinujecie. Czy w ogole jest wymagany podpis
kryptograficzny? Nie widzialem tu takiego wymagania i nie sądzę że
jest do czegoś potrzebne. W biurowym workflow zwykle wystarczy
informacja o decyzji kierownika zapisana gdzieś w dokumencie lub jego
historii - pokazać kierownikowi okienko decyzji i niech wybierze
odpowiednią opcję. Uwierzytelnieniem tego jest sama aplikacja ktora
zna id zalogowanego użytkownika - firma ufa swojej własnej
autentykacji, czy to domena czy cokolwiek innego. Zakładamy że tylko
kierownik zna swoje hasło do aplikacji i że każdy pracuje na swoim
koncie - ale to chyba normalne?
Po podjęciu decyzji można kierownikowi wysłać potwierdzenie mailem
albo smsem, żeby mógł zweryfikować czy się nie pomylił albo czy ktoś
się pod niego podszył - no i będzie miał ślad gdyby np ktoś zmienił
jego decyzję grzebiąc bezpośrednio w bazie.
Co do dodatkowych zabezpieczeń przed grzebaniem w bazach aplikacji -
pomysł z md5 jest chyba wystarczający, ale wg mnie to i tak za daleko
idące zabezpieczenie. Jeśli ktoś może grzebać w bazie to pwnie może
też np zmienić hasło domenowe i podszyć się pod innego użytkownika tak
że nikt tego nie wykryje. No ale jeśli firma nie ufa swoim adminom to
ma problem kadrowy a nie kryptograficzny.
R

do góry

On 2011-08-27, Edek <e...@g...com> wrote:
> [nie po kolei...]
> > Ty wez przeczytaj o czym inni pisza dobrze?
> >
>
> Point. Nie próbuję być ekspertem, którym nie jestem, może być, że
> nie wszystko od razu rozumiem.

To odpieprz się od próby implementowania podpisu cyfrowego, jeśli nie
czujesz się ekspertem od kryptografii. To nie jest coś co "się zrobi
i będzie dobrze", jak, nie przymierzając, system katalogowania książek
w bibliotece.

>>>>> Utrata klucza prywatnego powoduje, że trzeba zmienić klucz
>>>>> publiczny też.
>>>>
>>>> Kazdy system ma revoke.
>>>
>>> Utrata != poznanie przez osobę niepowołaną. Poza tym, stare dokumenty
>>> przy revoke trzeba by podpisać jeszcze raz, chyba że mają stempel
>>> czasu i ktoś magicznie wie, że klucz prywatny nie upublicznił się
>>> przed tą datą, wtedy można zrobić revoke od jakiejś daty. Można
>>> też mieć inny mechanizm, ale sam podpis PGP nie wystarczy.
>>>
>>> Czasami myli się revoke kluczy SSL z revoke kluczy podpisu. To
>>> drugie wpada w tą samą kategorię, co perfect forward secrecy.
>>
>> Jsli utraciles kontrole nad kluczem to znaczy ze jest publicznie znany.
>>
>
> Nie jestem ekspertem, ale chyba jednak nie.

Ale chyba jednak tak. Zawsze przy projektowaniu kryptosystemów zakłada
się najgorszy przypadek pasujący do modelu ataku.

> Ok: na USB (typu pendrive z plikami) jest klucz owinięty
> hasłem usera owinięty jednorazowym kluczem serwera podpisującego
> (wszystko symetrycznym).
>
> Samo zgubienie USB nie powoduje poznania klucza: bez hasła
> jest totalnie bezużyteczny. Natomiast powoduje jego utratę.
> Nie da się też łamać hasła bez znajomości klucza serwera.
>
> Czyli: można czytając A podpisać B, albo zamiast NIE AKCEPTUJE
> podpisać AKCEPTUJE.

Właściwie nie widzę jak można podpisać *cokolwiek* przy takim opisie
systemu.

> Jedyne, co widzę, to to, że nawet czytający podpisany dokument
> może czytać coś innego niż było podpisane. Pytanie jest o
> niezbędny poziom paranoi. Trzymam się wersji "dla ubogich".

Weź ty się lepiej zgłoś do jakiejś uczelni, która ma pracujący zespół
kryptologów i niech oni ci zaprojektują kryptosystem, a nie będziesz
paprał samodzielnie.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 08/29/2011 09:59 AM, nightwatch77 wrote:
> Dzizas, chłopaki, ale kombinujecie. Czy w ogole jest wymagany podpis
> kryptograficzny? Nie widzialem tu takiego wymagania i nie sądzę że
> jest do czegoś potrzebne. W biurowym workflow zwykle wystarczy
> informacja o decyzji kierownika zapisana gdzieś w dokumencie lub jego
> historii - pokazać kierownikowi okienko decyzji i niech wybierze
> odpowiednią opcję. Uwierzytelnieniem tego jest sama aplikacja ktora
> zna id zalogowanego użytkownika - firma ufa swojej własnej
> autentykacji, czy to domena czy cokolwiek innego. Zakładamy że tylko
> kierownik zna swoje hasło do aplikacji i że każdy pracuje na swoim
> koncie - ale to chyba normalne?
> Po podjęciu decyzji można kierownikowi wysłać potwierdzenie mailem
> albo smsem, żeby mógł zweryfikować czy się nie pomylił albo czy ktoś
> się pod niego podszył - no i będzie miał ślad gdyby np ktoś zmienił
> jego decyzję grzebiąc bezpośrednio w bazie.
> Co do dodatkowych zabezpieczeń przed grzebaniem w bazach aplikacji -
> pomysł z md5 jest chyba wystarczający, ale wg mnie to i tak za daleko
> idące zabezpieczenie. Jeśli ktoś może grzebać w bazie to pwnie może
> też np zmienić hasło domenowe i podszyć się pod innego użytkownika tak
> że nikt tego nie wykryje. No ale jeśli firma nie ufa swoim adminom to
> ma problem kadrowy a nie kryptograficzny.
> R

"pomysł z md5" to jak coś pomiędzy Diffie Hellman a Rijndaelem zgodnie
z wolą ludu do osiągnięcia prostego kompromisu i nie musi koniecznie
działać, to ostatnie ktoś w wątku już zauważył.

Co do reszty ogólnie masz rację, ale każdy system wokflow ma
logowanie się, więc w ogóle nie ma tematu.

Edek

do góry