Re: lug-bg: keyserver
- Subject: Re: lug-bg: keyserver
- From: vtzankov@xxxxxxxxxxx (Valentin Tzankov)
- Date: Tue, 05 Nov 2002 12:02:11 -0500
Clientite polzvat generirani 6-8 tzifrov codove bazirani na RSA Tokens za logvane
v sistemata i
certificat za criptirane na potoka. No za vseki user se dava X.509 Certifcat kojto
systo se zapisva v LDAP servera kojto pyk se polzva ot ACE/Server i prepolagam che
e tozi "seed record", ACE/Server e chast ot VPN i ne e chast ot prilojenieto vyrho
koeto rabotja, no ako te intersuva nesto koncretno moga da pitam. Potrebitelite na
systema comunikirat samo sys servera,
a ne pomejdu si zatova davajki im X.509 Certifcat kojto e generiran ot nashija
Root Certifcat raboti bez nikakyv problem mislja che ako izpolvzam PGP Certifcat
bi trjabvalo da e shodno.
Eto chast ot logicata kojato izpolzvam za proverka na certificate
imame tri X509Certificate koito sa chast ot the same chain
x509certificateRoot---> customerRootX509Certificate-->
customerGenerateX509certificate
Pri registratzija az generiram customerRootX509Certificate i mu go izprastam i go
zapisvam v LDAP servera
(tozi customerRootX509Certificate se generira vednyj i vaji za pravoto na dostyp
do systemata koeto e maximum 3 mesetza,
no obiknoveno se dava samo za 1 mesetz),
za da ustanovim SSL sessia clenta mi prasta customerGenerateX509certificate i ot
svoja strana proverjava
dali negovija customerRootX509Certificate e generiran ot moja x509certificateRoot
a servera ot svoja stran proverjava dali customerRootX509Certificate e generiran
ot negovija x509certificateRoot
Java code pri servera e nesto podobno , pri clienta se proverjava nashija
RootX509Certificate
s negovija customerRootX509Certificate, taka toj e sigoren che sme nie. Taka
negovija customerRootX509Certificate se transferira
samo vednyj i to obiknoveno prez druga prenosna sreda primerno E-Mail
public static boolean verify ( X509Certificate customerRootX509Certificate,
X509Certificate x509certificate,
String stringTarget )
Principal principalLast = customerRootX509Certificate.getSubjectDN();
Principal principalIssuer = x509certificate.getIssuerDN();
if (principalLast == x509certificate.getIssuerDN()) {
try{
PublicKey publickey = customerRootX509Certificate.getPublicKey();
x509certificate.verify(publickey);
} catch (GeneralSecurityException generalsecurityexception) {
System.out.println("signature verification
failed");
return false;
}
} else {
System.out.println("subject/issuer verification
failed");
return false;
}
}
Date date = new Date();
try {
x509certificate.checkValidity(date);
} catch (GeneralSecurityException generalsecurityexception) {
System.out.println("invalid date");
return false;
} ....................................................
Boris Jordanov wrote:
> -----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 ACE/Server 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
> ============================================================================
============================================================================
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
============================================================================
|