Re: lug-bg: keyserver

[borj@xxxxxxxxx (Boris Jordanov)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys, tuk neshto me oburkva...

On Monday 04 November 2002 17:30, Valentin Tzankov wrote:
> Znachi ot edin Private Key moje da generirash ogromen broj Public Keys.
>
> Tova za koeto govorja se proizvejda ot RSA, i e chast ot RSA SecurID System
> ustrojstvata se narichat RSA Tokens, nashija variant e dosta modificirana
> versia, ot tazi kojato se prodava kato gotovo reshenie,
> kato vsjako ustrojstvo "authenticator" ima  64-bit symmetric key v
> ustrojstvoto  e zapisan algorithm kojto generate a now
> code vseki 60 seconds. Na syrvera nie imame software RSA ACE/Server kojto
> proverjava dali codovete sa verni kato
> vjarnosta im e functzija na vremeto, t.e. vseki kljuch e validen samo 65sec
> t.e. 5 sec sled momenta v kojto se e smenil s nov code,

Znachi - izvadka ot publichno dostupen dokument (marketingov dori) ot site na 
Verisign:

RSA SecurID is based on patented, time-synchronous technology.

...

 1. User enters user name and passcode (the passcode is a four- to eight-digit 
random token code + the user s PIN)

2. Server and token compute token code by combining seed record and current 
Greenwich Mean Time

3. Server authenticates user by matching user passcode with server passcode

Dotuk njamame nikakvi serifikati...Produlzavam s dokumenta:

In time-synchronous authentication, both the token and the server (RSA 
ACE/Server) have internal clocks that are synchronized (hence,  
time-synchronous ). They also have identical seeds (a  seed  is the starting 
value used by a random number generation routine to create a pseudo-
random number). The seed is embedded within a token and generates a new token 
code every 60 seconds. The  seed record  is housed within the RSA ACE/Server 
software and generates the same token code at the same time. When the user 
enters the passcode, the server validates that this code matches its records 
at that point in time. If the code matches, the user is authenticated and 
granted access to protected resources.

> tazi zastita e validna samo pri ustanovjavane na sessia, i garantira che
> chovek kojto pritejava RSA Tokens se e lognal v systemata ni,
> tezi token-i sa bazirani na kljuch generiran na nashija   VeriSign Root
> Certificat.

Tova me navezda na misulta, che spomenatia po-gore "VeriSign Root Certificat" 
ili njama nishto obshto (vse oshte) sus SecurID authentikiraneto ili toj 
prosto e spomenatiat po-gore "seed record "

> Na vseki client predostavjame Certificat kojto e baziran na nashija Root
> Certificat  ot VeriSign, i kojto se transferira do clienta oste pri

Kakvo tochno poluchavat klientite vi? Sertifikati ili tokens? E tova me 
oburkva, Defakto, polzvajki tokens, ne e neobhodimo da se polzva Digital 
Certificates, zastoto billing sistema (ili kakvoto tam e) moze da kaze na 
tozi ACE/server - ami klienta mi podava tova tuk, ja kazi istinsko li e i toj 
da potvurdi/othvurli.

> registratzijata,  s kojto certificat nashija software generira public key,
> kojto e razlichen pri vsjaka sessia i se izpolzva za kodirane  na VoIP
> packetite, tozi public key se izprasta na nashija server.

Tova e nepriemlivo - veche beshe objasneno, zashto za podobni zadachi se 
izpolzvat symetric keys - po-burzo, po-leko, rabotata na Public i Private 
keys (sertifikatite izobshto) e da osigurjat _siguren_ obmen na symetric 
key-a, kato dokazat identity-to na dvete strani koito shte komunikirat i da 
osigurjat siguren nachalen kanal za obmjana na symetric key-a (narichan i 
sesien kluch), ot tam natatuk, po vreme na sesiata, pak s pomoshtta na 
kluchovete moze da se generirat novi sesiini kluchove, prez opredelen 
interval ot vreme, s cel oshte po-visoka sigurnost (namaljavane riska ot 
statisticheski analiz na potoka danni) A kak dve strani pritezavashti 
sertifikati izdadeni ot treta (Certificate Authority - CA) udostvoverjavat 
samolichnostta si - Strani A i B sa klienti, C e root authority (tam e root 
certificate (kojto moze i da e self signed, ako ne operirate izvun vashata 
organizacia s podpisanite ot nego sertifikati, btw, te i Verisign 
certificates sa self-signed :) )) A i B generirat zajavka za sertifikat i go 
prashtat na RA - registration authority (moze da bude i human operator) 
proverjava validnostta na zajavkite i prochhe i ako sa OK, kazva na CA - OK 
e. CA sus svoja private key podpisva public key-a na A i mu vrushta taka 
podpisania key. Ot tuk natatuk certificate na A e negovia public key + 
sushtia tozi public key sign-at ot CA. Sushtoto stava i s B. Ot tuk natatuk e 
neobhodim siguren kanal za poluchavane na CA certificata ot vsjaka strana, 
zastoto ne moze da iskame ako A i B imat certificates tova da e dostatuchno 
za da si govorjat. Trjabva da imat certificates ot authorities, koito sa 
_trusted_ i za A, i za B. Tozi siguren kanal moze da e naprimer - CA 
sertifikat na disketka i go transferirame do vsjaka strana i go importvame 
tam kato trusted CA. Kak stava na praktika "razpoznavaneto" A izprashta 
cert-a si na B, a B svoja na A. A vzema poluchenia pubkey ot certificate i mu 
pravi hash, vzema i podpisania ot CA pubkey(defakto tove e hash na pubkey-a 
cryptnat s private key na CA) na B i polzvajki pubkey-a na CA (zatova trjabva 
da imame root certificate pod ruka) decryptira podpisania pubkey i poluchava 
oshte edin hash - ako suvpadat - OK, B naistina e B. B izvurshva analogichna 
procedura.

Otpusnah se v objasnenia, zashtoto ne moza da vurza tazi shema (malko ja 
oprostih) sus SecurID shemata. Ili puk s tezi multiple public keys. Njama 
takova zivotno 1 private many public.

> Nashija server ot svoja strana poverja dali public key e bzairan na primary
> key generiran ot nashija server ako e taka,
> generira i izprasta public key do clentskija software kojto se proverjava i
> ako vskichko OK se zapochva transfera.

Moze li po-jasni objasnenia plz. tova pone za men e oburkvashto.

- --
Take care

Boris Jordanov (borj) <borj@xxxxxxxxx>
ICQ 10751645

PGP-key-fingerprint:------------------------------
CB23 8B52 5FBC F36A 1B61  F1ED 2831 E52D AAFF 7B08
- --------------------------------------------------
Public-key:---------------------------------------
http://borj.freeshell.org/borj.asc
- --------------------------------------------------
To err is human...
to really foul up requires the root password.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9x7V1KDHlLar/ewgRArziAJ4zQpOEEd3n+lwF5FX4SI2+M5JiMwCgnJFJ
o9OmmhyBpzfBh5iT7mlTkzc=
=iXKf
-----END PGP SIGNATURE-----

============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================