Luota kaikkiin? Älä luota keneenkään? Kuulostaa vähän kuin Salaiset kansiot, mutta kun on kyse luottamuksellisista tiedoista, on tärkeää tietää, kuka olet ja johon luotat, kuin tietää, mihin luotat heitä. Tämä käsite on yhtä tärkeä sovelluksille kuin ihmisille. Loppujen lopuksi olemme tehneet sovelluksista tietojen säilyttäjiä ja resurssejamme. Se on totta koko yrityksessä - sovelluksissa on kriittistä tietoa yrityksestämme ja asiakkaistamme - ja se on totta työpöydällä. En voi kertoa, kuinka monta kertaa minulta on kysytty, kuinka kirjoitetaan sovelma, joka skannaa käyttäjän aseman, jotta yksi käyttäjä voi komentaa toisen käyttäjän selainta tai siepata yksityisiä tietoja.
Java, koska se on verkon kehittämisalusta, on joutunut ratkaisemaan luottamuksen ongelman etupäässä. Tuloksena on Java Security API ja Java Cryptography Architecture.
Lyhyt vilkaisu taaksepäin
Ennen kuin sukelan suoraviivaisesti API: iin, koodiin ja kommentteihin, haluaisin palata lyhyesti viime kuussa käytyyn keskusteluun. Jos liityt meihin ensimmäistä kertaa, sinun kannattaa varmuuskopioida kuukausi ja lukea "Allekirjoitettu ja toimitettu: Johdatus turvallisuuteen ja todennukseen". Tämä sarake tarjoaa perusteellisen johdannon kaikkiin termeihin ja käsitteisiin, joita käytän tässä kuussa.
Suojaus ja todennus käsittelevät kahta keskeistä huolenaihetta: viestin todistamista on luonut tietty taho, eikä viestin todistamiseen puututa sen luomisen jälkeen. Yksi tapa saavuttaa molemmat tavoitteet on käyttää digitaalisia allekirjoituksia.
Digitaaliset allekirjoitukset riippuvat suuresti salauksen haarasta, joka tunnetaan julkisen avaimen salauksena. Julkisen avaimen algoritmeille on tunnusomaista se, että ne luottavat sovitettuun avainpariin (yksi yksityinen ja yksi julkinen) pikemminkin kuin yhteen avaimeen. Yhteisö pitää yksityisen avaimen salassa, mutta asettaa julkisen avaimen saataville.
Digitaalisen allekirjoituksen algoritmi ottaa syötteenä viestin ja yksikön yksityisen avaimen ja luo digitaalisen allekirjoituksen. Digitaalinen allekirjoitus luodaan siten, että kuka tahansa voi ottaa yrityksen julkisen avaimen ja käyttää sitä varmistaakseen, että yhteisö tosiasiallisesti allekirjoitti kyseisen viestin. Lisäksi, jos alkuperäistä viestiä on peukaloitu, allekirjoitusta ei voida enää tarkistaa. Digitaaliset allekirjoitukset tarjoavat yhden lisäedun: Kun yhteisö on allekirjoittanut ja jakanut viestin, sen alullepanijan on mahdotonta kieltää allekirjoittaneensa viestiä (väittämättä, että hänen yksityinen avain on varastettu).
Moottoreista ja toimittajista
Java Cryptography -sovellusliittymä määrittelee Java-työkalupaketin suojausta ja todennusta varten. Java-salausarkkitehtuuri (JCA) kuvaa käyttöliittymän käyttöä. Parhaan joustavuuden varmistamiseksi sekä kehittäjälle että loppukäyttäjälle JCA: ssa on kaksi pääperiaatetta:
Arkkitehtuurin tulisi tukea algoritmien riippumattomuutta ja laajennettavuutta. Kehittäjän on voitava kirjoittaa sovelluksia sitomatta niitä liian lähelle tiettyä algoritmia. Lisäksi uusia algoritmeja kehitettäessä ne on integroitava helposti olemassa oleviin algoritmeihin.
Arkkitehtuurin tulisi tukea toteutuksen riippumattomuutta ja yhteentoimivuutta. Kehittäjän on voitava kirjoittaa sovelluksia sitomatta niitä tiettyyn toimittajan algoritmin toteutukseen. Lisäksi eri toimittajien tarjoaman algoritmin toteutusten on oltava yhteentoimivia.
Näiden kahden vaatimuksen täyttämiseksi Java Cryptography -sovellusliittymän kehittäjät perustivat suunnittelunsa moottorijärjestelmään.
Moottorit tuottavat ilmentymiä viestien muodostamiseen, digitaalisen allekirjoituksen generaattoreihin ja avainparin generaattoreihin. Kutakin esiintymää käytetään vastaavan toiminnon suorittamiseen.
JCA: n kanoninen moottori on luokka, joka tarjoaa nimeltään staattisen menetelmän (tai menetelmät) getInstance (), joka palauttaa luokan ilmentymän, joka toteuttaa kryptografisesti merkitsevän algoritmin. getInstance () menetelmä tulee sekä yhden argumentin että kahden argumentin muodossa. Molemmissa tapauksissa ensimmäinen argumentti on algoritmin nimi. JCA tarjoaa luettelon standardinimistä, vaikka kaikkia ei toimiteta missään tietyssä julkaisussa. Toinen argumentti valitsee palveluntarjoajan.
SUN-palveluntarjoaja
Vain yksi palveluntarjoaja - AURINKO - toimitetaan JDK 1.1: ssä. SUN tarjoaa sekä NIST-digitaalisen allekirjoituksen algoritmin (DSA) toteutuksen että MD5- ja NIST SHA-1 -viestien yhteenvetoalgoritmien toteutuksen.
Luokan MessageDigest
Aloitamme tarkastelemalla koodia, joka tuottaa viestistä tiivistelmän viestistä.
MessageDigest messagedigest = MessageDigest.getInstance ("SHA");
MessageDigest messagedigest = MessageDigest.getInstance ("SHA", "SUN");
Kuten mainitsin vain hetki sitten, getInstance () menetelmää on kahta makua. Ensimmäinen edellyttää vain algoritmin määrittämistä. Toinen edellyttää sekä algoritmin että palveluntarjoajan määrittämistä. Molemmat palauttavat luokan ilmentymän, joka toteuttaa SHA-algoritmin.
Seuraavaksi välitämme viestin viestin muodostusgeneraattorin kautta.
int n = 0; tavu [] rgb = uusi tavu [1000]; while ((n = inputstreamMessage.read (rgb))> -1) {messagedigest.update (rgb, 0, n); }
Tässä oletetaan, että viesti on käytettävissä tulovirrana. Tämä koodi toimii hyvin suurille viesteille, joiden pituus on tuntematon. päivittää() method hyväksyy myös yhden tavun argumenttina muutaman tavun pituisille viesteille ja tavutaulukon kiinteän tai ennustettavan kokoisille viesteille.
rgb = messagedigest.digest ();
Viimeinen vaihe käsittää viestin muodostamisen itse. Tuloksena oleva tiivistelmä koodataan joukkoina tavuja.
Kuten näette, JCA kätkee kätevästi kaikki matalan tason toteutus- ja algoritmikohtaiset yksityiskohdat, jolloin voit työskennellä korkeammalla, abstraktimmalla tasolla.
Tietysti yksi tällaisen abstraktin lähestymistavan riskeistä on lisääntynyt todennäköisyys, ettemme tunnista virheistä johtuvaa virheellistä tulostusta. Kun otetaan huomioon salaus, tämä voi olla merkittävä ongelma.
Harkitse "off-by-one" -virhettä alla olevassa päivitysrivissä:
int n = 0; tavu [] rgb = uusi tavu [1000]; while ((n = inputstreamMessage.read (rgb))> -1) {messagedigest.update (rgb, 0, n - 1); }
C. Yllä oleva koodi kääntyy, ja suoritettava tiedosto toimii ilman virheitä tai varoituksia, mutta tuloksena oleva viestin tiivistelmä on väärä.
Onneksi JCA on hyvin harkittu ja hyvin suunniteltu, joten edellä mainitun kaltaiset mahdolliset sudenkuopat ovat suhteellisen harvinaisia.
Ennen kuin siirrymme avainparin generaattoreihin, katsokaa
MessageDigestGenerator, ohjelman lähdekoodi, joka tuottaa viestin tiivistelmän.
Luokan KeyPairGenerator
Digitaalisen allekirjoituksen (ja salauksen) luomiseksi tarvitsemme avaimet.
Avainten luominen algoritmista riippumattomassa muodossaan ei ole oleellisesti vaikeampi kuin viestin tiivistelmän luominen ja käyttö.
KeyPairGenerator keypairgenerator = KeyPairGenerator.getInstance ("DSA");
Kuten yllä olevassa viestin tiivistelmäesimerkissä, tämä koodi luo luokan ilmentymän, joka tuottaa DSA-yhteensopivat avaimet. Toinen (tarvittaessa) argumentti määrittää palveluntarjoajan.
Kun avainparin generaattori-ilmentymä on luotu, se on alustettava. Voimme alustaa avainparin generaattorit kahdella tavalla: algoritmista riippumaton tai algoritmista riippuva. Käyttämäsi menetelmä riippuu lopputuloksen hallinnan määrästä.
keypairgenerator.initialize (1024, uusi SecureRandom ());
Eri algoritmeihin perustuvat avaimet eroavat toisistaan niiden luomisen suhteen, mutta niillä on yksi yhteinen parametri - avaimen parametrit vahvuus. Vahvuus on suhteellinen termi, joka vastaa suunnilleen sitä, kuinka vaikeaa avain on "murtua". Jos käytät algoritmista riippumatonta alustusohjelmaa, voit määrittää vain voimakkuuden - kaikki algoritmista riippuvat arvot ottavat kohtuulliset oletusarvot.
DSAKeyPairGenerator dsakeypairgenerator = (DSAKeyPairGenerator) avainparin generaattori; DSAParams dsaparams = uudet DSAParams () {private BigInteger p = BigInteger (...); yksityinen BigInteger q = BigInteger (...); yksityinen BigInteger g = BigInteger (...); julkinen BigInteger getP () {return p; } public BigInteger getQ () {return q; } julkinen BigInteger getG () {return g; }}; dsakeypairgenerator.initialize (dsaparams, uusi SecureRandom ());
Vaikka oletukset ovat yleensä riittävän hyviä, jos tarvitset enemmän hallintaa, se on käytettävissä. Oletetaan, että käytit moottoria DSA-yhteensopivien avainten generaattorin luomiseen, kuten yllä olevassa koodissa. Kulissien takana moottori latasi ja suoritti esimerkin luokan, joka toteuttaa DSAKeyPairGenerator käyttöliittymä. Jos heitämme saamamme yleisen avainparin generaattorin DSAKeyPairGenerator, saamme sitten pääsyn algoritmista riippuvaan alustusmenetelmään.
DSA-avainparin generaattorin alustamiseksi tarvitsemme kolme arvoa: prime P, subprime Q, ja pohja G. Nämä arvot kaapataan sisäisen luokan esiintymässä, joka välitetään alustaa() menetelmä.
SecureRandom luokka tarjoaa suojatun satunnaislukujen lähteen, jota käytetään avainparien luomisessa.
return keypairgenerator.generateKeyPair ();
Viimeinen vaihe on itse avainparin luominen.
Ennen kuin siirrymme digitaalisiin allekirjoituksiin, tutustu KeyToolsiin, avaimen paria tuottavan ohjelman täydelliseen lähdekoodiin.
Luokan allekirjoitus
. -. Instanssin luominen ja käyttö Allekirjoitus luokka ei ole oleellisesti erilainen kummastakaan edellisestä esimerkistä. Erot ovat siinä, miten instanssia käytetään - joko allekirjoittamaan tai vahvistamaan viesti.
Allekirjoituksen allekirjoitus = Signature.getInstance ("DSA");
Aivan kuten aiemmin, käytämme moottoria sopivan tyyppisen esiintymän saamiseksi. Se, mitä teemme seuraavaksi, riippuu siitä, allekirjoittammeko vai vahvistammeko viestin.
allekirjoitus.initSign (yksityisavain);
Viestin allekirjoittamiseksi meidän on ensin alustettava allekirjoitusilmentymä viestin allekirjoittavan yksikön yksityisellä avaimella.
allekirjoitus.initVerify (publickey);
Viestin vahvistamiseksi meidän on alustettava allekirjoitusilmentymä sen yksikön julkisella avaimella, joka väittää allekirjoittaneensa viestin.
int n = 0; tavu [] rgb = uusi tavu [1000]; while ((n = inputstreamMessage.read (rgb))> -1) {allekirjoitus.päivitys (rgb, 0, n); }
Seuraavaksi, riippumatta siitä, allekirjoittammeko vai tarkistammeko, meidän on siirrettävä viesti allekirjoitusgeneraattorin kautta. Huomaat kuinka samanlainen prosessi on aikaisempaan esimerkkiin viestin tiivistelmän luomisesta.
Viimeinen vaihe koostuu allekirjoituksen luomisesta tai allekirjoituksen vahvistamisesta.
rgb = allekirjoitus.merkki ();
Jos allekirjoitamme viestin, merkki() method palauttaa allekirjoituksen.
allekirjoitus.verify (rgbSignature);
Jos tarkistamme viestistä aiemmin luodun allekirjoituksen, meidän on käytettävä tarkista () menetelmä. Se ottaa parametrina aiemmin luodun allekirjoituksen ja määrittää, onko se edelleen voimassa.
Ennen kuin yhdistämme asiat, tutustu Sign.java-viestiin, joka on viestin allekirjoittavan ohjelman täydellinen lähdekoodi, ja Verify.java, joka on täydellinen lähdekoodi ohjelmalle, joka vahvistaa viestin.
Johtopäätös
Jos käsivarret itseäsi työkaluilla ja tekniikoilla, jotka olen esittänyt tässä kuussa, olet enemmän kuin valmis suojaamaan sovelluksesi. Java Cryptography -sovellusliittymä tekee prosessista melkein vaivatonta. Java Developers Kitin julkaisu 1.2 lupaa vielä enemmän. Pysy kanavalla.
Ensi kuussa palaan takaisin väliohjelmistoalueelle. Otan pienen RMI: n, jonkin verran ketjuttamista ja kasan koodia, ja näytän sinulle, kuinka voit rakentaa oman viestikeskeisen väliohjelmiston.
Todd Sundsted on kirjoittanut ohjelmia siitä lähtien, kun tietokoneita tuli saataville sopivissa työpöytämalleissa. Vaikka Todd oli alun perin kiinnostunut hajautettujen objektisovellusten rakentamisesta C ++: ssa, Todd siirtyi Java-ohjelmointikielelle, kun siitä tuli itsestään selkeä valinta sellaiselle. Kirjoituksen lisäksi Todd on Etceen toimitusjohtaja, joka tarjoaa koulutus-, mentorointi-, konsultointi- ja ohjelmistokehityspalveluja.Lisätietoja tästä aiheesta
- Lataa täydellinen lähdekoodi //www.javaworld.com/jw-01-1999/howto/jw-01-howto.zip
- Java Security -sovellusliittymän yleiskatsaus //www.javasoft.com/products/jdk/1.1/docs/guide/security/JavaSecurityOverview.html
- Java-kryptografiaarkkitehtuuri //www.javasoft.com/products/jdk/1.1/docs/guide/security/CryptoSpec.html
- Sunin Java-suojaussivu //java.sun.com/security/index.html
- RSA: n salauksen usein kysytyt kysymykset //www.rsa.com/rsalabs/faq/
- Salauskäytäntö ja tiedot //www.crypto.com/
- Lue Toddin edelliset How-To Java -sarakkeet //www.javaworld.com/topicalindex/jw-ti-howto.html
Tämän tarinan "Java luotamme" julkaisi alun perin JavaWorld.
