Michal Kawecki <kkwinto> writes:

> Specyfikacja tego malenstwa (patrz post wyzej) wyglada raczej
> zachecajaco. Trudno z góry zakladac, ze sa to tylko iluzje.

Ale to nie definiuje mechanizmow, ktore sa wykorzystywany. Samo
napisanie "AES" itp. nie gwarantuje dokladnie niczego.

Dnia Fri, 08 Jan 2010 17:33:54 +0100, MarcinF napisał(a):

> Michal Kawecki wrote:
>
>> Weź mnie nie osłabiaj. Piszemy na grupie security, jeśli nie zauważyłeś.
>>
>> A co do meritum pytania - oczywiście, że kłopot. Nigdy nie daję hasła do
>> konta administratora userom na ich służbowych notebookach.
>
> Alez nie chcialem zeby komukolwiek zrobilo sie slabo :)
>
> Chyba nikt do tej pory nie wspominal ze ta dyskusja dotyczy przypadku
> kiedy ktos inny administruje systemem.

No dobrze. Weźmy więc przypadek, kiedy wpinasz pena z danymi do obcej
maszyny, do której nie znasz hasła administratora. Dasz radę zamontować
na niej kontener zaszyfrowany Truecryptem? Nie? No to już wiesz,
dlaczego peny szyfrowane sprzętowo są super.

> A nawet gdyby to w bezpiecznym centralnie zarzadzanym srodowisku to nie uzytkownik
> powinien decydowac o tym jaki nosnik moze podlaczyc, jakie dane skopiowac i co zaszyfrowac itd.

A co to ma w ogóle do rzeczy? Załóżmy, że to ja o tym decyduję. W jaki
sposób poprawia to używalność sprzętu, do którego obsługi trzeba podać
userowi hasło administratora?

> Poza tym jak uzytkownik moze skutecznie zabezpieczyc dane przed administratorem
> systemu ? :)

Większość poważnych rozwiązań szyfrujących opiera się na zasadzie, że
poświadczenia dostępu do danych zna tylko ich właściciel. Rola
administratora powinna się sprowadzać jedynie do umożliwienia
odtworzenia danych z backupu po ich ewentualnej utracie. Nie chciałbym
pracować w firmie, gdzie Ty jako administrator mógłbyś wtykać nos w moje
poufne pliki...

Dnia Fri, 08 Jan 2010 19:12:07 +0100, Krzysztof Halasa napisal(a):

> Michal Kawecki <kkwinto> writes:
>
>> Specyfikacja tego malenstwa (patrz post wyzej) wyglada raczej
>> zachecajaco. Trudno z góry zakladac, ze sa to tylko iluzje.
>
> Ale to nie definiuje mechanizmow, ktore sa wykorzystywany. Samo
> napisanie "AES" itp. nie gwarantuje dokladnie niczego.

Ale tu nie ma problemu z samym mechanizmem szyfrowania, tylko z
weryfikacja wpisanego hasla, która jest wykonywana w pamieci komputera
zamiast w USB penie. Co oczywiscie bynajmniej nie umniejsza wagi
problemu.

"NIST-certified USB Flash drives with hardware encryption cracked

Encrypting USB Flash memory from Kingston, SanDisk and Verbatim
Kingston, SanDisk and Verbatim all sell quite similar USB Flash drives
with AES 256-bit hardware encryption that supposedly meet the highest
security standards. This is emphasised by the FIPS 140-2 Level 2
certificate issued by the US National Institute of Standards and
Technology (NIST), which validates the USB drives for use with sensitive
government data. Security firm SySS, however, has found that despite
this it is relatively easy to access the unencrypted data, even without
the required password.

The USB drives in question encrypt the stored data via the practically
uncrackable AES 256-bit hardware encryption system. Therefore, the main
point of attack for accessing the plain text data stored on the drive is
the password entry mechanism. When analysing the relevant Windows
program, the SySS security experts found a rather blatant flaw that has
quite obviously slipped through testers' nets. During a successful
authorisation procedure the program will, irrespective of the password,
always send the same character string to the drive after performing
various crypto operations – and this is the case for all USB Flash
drives of this type.

Cracking the drives is therefore quite simple. The SySS experts wrote a
small tool for the active password entry program's RAM which always made
sure that the appropriate string was sent to the drive, irrespective of
the password entered and as a result gained immediate access to all the
data on the drive. The vulnerable devices include the Kingston
DataTraveler BlackBox, the SanDisk Cruzer Enterprise FIPS Edition and
the Verbatim Corporate Secure FIPS Edition.

When notified by SySS about this worst case security scenario, the
respective vendors responded quite differently. Kingston started a
recall of the affected products; SanDisk and Verbatim issued woolly
security bulletins about a "potential vulnerability in the access
control application" and provided a software update. When asked by heise
Security, Verbatim Europe said that none of the affected drives have
been sold in Europe – and that none will be shipped before the hole has
been closed.

The real question, however, remains unanswered – how could USB Flash
drives that exhibit such a serious security hole be given one of the
highest certificates for crypto devices? Even more importantly, perhaps
– what is the value of a certification that fails to detect such holes?"

Zródlo:
http://www.h-online.com/security/new...ed-895308.html

Michal Kawecki <kkwinto> writes:

> Ale tu nie ma problemu z samym mechanizmem szyfrowania, tylko z
> weryfikacja wpisanego hasla, która jest wykonywana w pamieci komputera
> zamiast w USB penie. Co oczywiscie bynajmniej nie umniejsza wagi
> problemu.

Problemem jest to, ze pendrive zawiera klucz w dostepnej postaci.

> The USB drives in question encrypt the stored data via the practically
> uncrackable AES 256-bit hardware encryption system. Therefore, the main
> point of attack for accessing the plain text data stored on the drive is
> the password entry mechanism. When analysing the relevant Windows
> program, the SySS security experts found a rather blatant flaw that has
> quite obviously slipped through testers' nets. During a successful
> authorisation procedure the program will, irrespective of the password,
> always send the same character string to the drive after performing
> various crypto operations – and this is the case for all USB Flash
> drives of this type.

Niestety nie wiem o jaki "character string" chodzi, tu nie ma
konkretnych informacji.

> Cracking the drives is therefore quite simple. The SySS experts wrote a
> small tool for the active password entry program's RAM which always made
> sure that the appropriate string was sent to the drive, irrespective of
> the password entered and as a result gained immediate access to all the
> data on the drive. The vulnerable devices include the Kingston
> DataTraveler BlackBox, the SanDisk Cruzer Enterprise FIPS Edition and
> the Verbatim Corporate Secure FIPS Edition.

Wydaje sie ze tam haslo nie ma w ogole zwiazku z kluczem szyfrujacym.
Dziwne rzeczy. "Normalnie" (bez sensu, ale to statystycznie czeste
"rozwiazanie") haslo jest wysylane do urzadzenia, i to decyduje czy dac
dostep czy tez nie. Zwykle latwe do zlamania, ale nie az tak trywialnie.

Sensowny sposob zrobienia takiego pendrive jest taki: user wpisuje
haslo, program wysyla je do pendrive, scalak w srodku na podstawie hasla
generuje klucz do szyfrowania, ew. robi jakies trywialne testy by
stwierdzic czy klucz/haslo sa sensowne, i szyfruje algorytmem uznanym za
wzglednie bezpieczny do takich zastosowan (zaden tam tylko AES-256 ani
zaden algorytm ze znanymi slabosciami).
Jesli user wpisze zle haslo, to byc moze zostanie to wykryte przez test
(jesli bedzie mial szczescie). Jesli user wpisze dobre haslo, to
wygenerowany klucz bedzie dobry i dostanie dostep.
Sa tu jeszcze kwestie ilosci bitow losowych hasla itd, ale to juz nieco
inna kategoria problemow niz te opisane.

> When notified by SySS about this worst case security scenario, the
> respective vendors responded quite differently. Kingston started a
> recall of the affected products; SanDisk and Verbatim issued woolly
> security bulletins about a "potential vulnerability in the access
> control application" and provided a software update.

Nie wiem co to ma dac, jesli wystarczy starsza wersja oprogramowania
i mamy dostep? Mam wrazenie ze osoba piszaca nie do konca wie o co
chodzi.

> The real question, however, remains unanswered – how could USB Flash
> drives that exhibit such a serious security hole be given one of the
> highest certificates for crypto devices?

Temu sie akurat tak bardzo bym nie dziwil.

> Even more importantly, perhaps
> – what is the value of a certification that fails to detect such holes?"

To tez zalezy dla kogo ma byc ta wartosc.

Michal Kawecki wrote:

> Rola administratora powinna się sprowadzać jedynie do umożliwienia

a skad user ma miec pewnosc do czego sie sprowadza faktycznie?

chodzi mi o to ze jesli komus bardzo zalezy na bezpieczenstwie to nie
bedzie korzystal z systemu ktorego nie kontroluje, wiec jaki jest
sens uzywania narzedzia do szyfrowania bez praw administratora ?

Dnia Sun, 10 Jan 2010 22:03:14 +0100, MarcinF napisał(a):

> Michal Kawecki wrote:
>
>> Rola administratora powinna się sprowadzać jedynie do umożliwienia
>
> a skad user ma miec pewnosc do czego sie sprowadza faktycznie?
>
> chodzi mi o to ze jesli komus bardzo zalezy na bezpieczenstwie to nie
> bedzie korzystal z systemu ktorego nie kontroluje, wiec jaki jest
> sens uzywania narzedzia do szyfrowania bez praw administratora ?

Podkręć może jasność wypowiedzi. Chodzi Ci o to, że bez znajomości hasła
administratora do firmowego systemu operacyjnego nie będziesz korzystał
na nim z szyfrowania danych, bo go nie kontrolujesz? Znaczy, nie ufasz
własnemu administratorowi?

Krzysztof Halasa pisze:
> Marek <marek.grupy> writes:
>> I teraz pytanie. Z opisu wynika, ze mam tu sprzetowe szyfrowanie
>> zapisywanych danych algorytmem AES 256. Skoro tak byloby to dlaczeog da sie
>> to relatywnie latwo zlamac ??? GDzie jest luka ? Bo z komentarzy wnosze, ze
>> trueCrypt jest skuteczniejszy...
>
> Algorytm stosowany przez truecrypt jest jawny. Nie znam go, nie uzywam,
> ale domyslam sie, ze klucz jest generowany na podstawie hasla, tzn. to
> nie jest tak, ze gotowy klucz jest np. na dysku i tylko haslo jest
> sprawdzane przed uzyciem klucza.
Oidp wyglada to tak, ze jest jeden klucz w calosci generowany losowo
(sluzacy do szyfrowania danych), który jest szyfrowany kluczem
generowanym z hasla (dobrze posolongo) i zapisywany z danymi. Dzieki
temu mozna haslo zmienic bez potrzeby szyfrowania calosci ponownie.

Nie wiem, czy przy pendrive'ach tez, ale czytalem, ze truecrypt mial
dosc ciekawe podejscie do kwestii soli - nie zapisywal jej, a zgadywal
bruteforcem dzieki czemu sprawdzanie poprawnosci hasla zajmowalo kilka
tysiecy cykli "z hasla i soli wygeneruj klucz, odszyfruj blok glówny,
sprawdz, czy jest prawidlowy".

Michal Kawecki wrote:

> Znaczy, nie ufasz własnemu administratorowi?

a jest jakis powod z jakiego nalezaloby ufac administratorowi ?

nawet jesli przyjmiemy takie hipotetyczne zalozenie swiata w ktorym
osobie administratora sie ufa, to dalej zostaje mozliwosc ze ktos
nie bedacy administratorem jakos pozyska jego prawa, a dodatkowo
im wiecej osob z uprawnieniami administratora to tym wieksze
niebezpieczenstwo

MarcinF pisze:
> Michal Kawecki wrote:
>
> > Znaczy, nie ufasz własnemu administratorowi?
>
> a jest jakis powod z jakiego nalezaloby ufac administratorowi ?
>
> nawet jesli przyjmiemy takie hipotetyczne zalozenie swiata w ktorym
> osobie administratora sie ufa, to dalej zostaje mozliwosc ze ktos
> nie bedacy administratorem jakos pozyska jego prawa, a dodatkowo
> im wiecej osob z uprawnieniami administratora to tym wieksze
> niebezpieczenstwo
>
Używasz systemu operacyjnego, który sam napisałeś i komputera, który sam
zrobiłeś, czy ufasz tym kilku tysiącom inżynierów?

Michoo wrote:

> Używasz systemu operacyjnego, który sam napisałeś i komputera, który sam
> zrobiłeś, czy ufasz tym kilku tysiącom inżynierów?

moznaby tak filozofowac w nieskonczonosc, ale zaczelo sie od roznic
miedzy truecryptem wymagajacym praw administratora, a rozwiazaniem
sprzetowym ktore moze tego nie wymagac, a wiec byc wygodniejszym w uzyciu

w obu przypadkach korzystanie bez praw administratora niesie ze soba
jakies ryzyko, przed ktorym akurat tworcy truecrypta wyraznie
ostrzegaja http://www.truecrypt.org/docs/?s=non-admin-users

rozumiem tez ze kazdy moze miec inne zdanie, bo bezpieczenstwo
to czesto kwestia dosc subiektywna

MarcinF pisze:
> Michoo wrote:
>> moznaby tak filozofowac w nieskonczonosc, ale zaczelo sie od roznic
> miedzy truecryptem wymagajacym praw administratora, a rozwiazaniem
> sprzetowym ktore moze tego nie wymagac, a wiec byc wygodniejszym w uzyciu
>
> w obu przypadkach korzystanie bez praw administratora niesie ze soba
> jakies ryzyko, przed ktorym akurat tworcy truecrypta wyraznie
> ostrzegaja [..]
>
> rozumiem tez ze kazdy moze miec inne zdanie, bo bezpieczenstwo
> to czesto kwestia dosc subiektywna
>
Nie rozumiesz - twórcy ostrzegają przed sytuacją w której korzystasz z
'jakiegoś' komputera na którym zainstalowany jest TC - mógł on zostać
spreparowany przez jego administratora.

Natomiast jeżeli mówimy o administratorze w sensie pracownika
zajmującego się działaniami administracyjnymi to albo mu ufasz, że NIE
będzie Cię sabotował, albo go zwalniasz(lub też nie posiadasz
administratora), bo twój komputer może spreparować w ciągu minuty bez
znajomości hasła - starczy go odpalić z płyty.

Michoo <michoo_news> writes:

> Oidp wyglada to tak, ze jest jeden klucz w calosci generowany losowo
> (sluzacy do szyfrowania danych), który jest szyfrowany kluczem
> generowanym z hasla (dobrze posolongo) i zapisywany z danymi. Dzieki
> temu mozna haslo zmienic bez potrzeby szyfrowania calosci ponownie.

Zapewne jakos tak jest.

> Nie wiem, czy przy pendrive'ach tez

Przy akurat tych tak byc nie moze, jesli mozna uzyskac rozszyfrowane
dane bez znajomosci (zgadywania itd) hasla - tylko po prostu uzywajac
starszej wersji oprogramowania.

No chyba ze to oprogramowanie mialo taka wade, ze zamiast dobrze
wylosowac klucz do szyfrowania blokowego, zawsze generowalo ten sam.
Wtedy poprawienie bledu(?) w sofcie + ponowne "sformatowanie" (czy jak
sie to tam nazywaloby) pendrive eliminowaloby problem.
Ale czy to tak jest to nie mam pojecia. Obawiam sie ze ten dziennikarz,
czy kto to tam byl, takze nie.