Java security - praca z kluczami i certyfikatami

Transkrypt

1 Java security - praca z kluczami i certyfikami Wstęp Generalnie zabawa z kluczami może okazać się kłopotliwa, gdy nie posiada się wiedzy o stojącej za nimi idei oraz zastosowanych rozwiązaniach. Na początek warto wiedzieć, że magazyny kluczy JAVA (JKS) przechowują razem certyfiky oraz klucze prywne i publiczne. Narzędzia keytool (z dystrybucji jdk) oraz ssh-keygen (znane z generowania kluczy ssh prywnych i publicznych) to nie to samo. keytool operuje na magazynie kluczy i certyfików (do magazynu można dodać wiele kluczy i certyfików), nomiast ssh-keygen obsługuje tylko pojedynczą parę kluczy (składającą się z klucza prywnego i publicznego). Można o tym poczytać na stronach: Podpisywanie plików jar oraz ich użycie Scenariusze na stronach Oracle Na stronach internetowych Oracle opisano scenariusze: podpisywania powstałego oprogramowania: er.html wykorzystania podpisanego oprogramowania: iver.html Poniżej opisano w szczegółach scenariusz pozwalający na uruchomienie aplikacji korzystającej z zewnętrznej biblioteki (pliku jar) podpisanej wygenerowanym certyfikem. Oparto go na przykładzie eclipsowych projektów Biblioteka01 oraz Aplikacja Generowanie kluczy Wygeneruj parę kluczy i zapisz ją w repozytorium kluczy: $ keytool -genkeypair -keyalg rsa -keysize alias tkubik - keystore tkubikkeys.jks -dname "CN=Tomasz Kubik" Powyższe wygeneruje jednocześnie podpisany samemu certyfik (ang. self-signed-certifice). W ogólności wystarcza on do przeprowadzania testów podczas realizacji ćwiczenia.

2 2. Podpisanie certyfiku (krok opcjonalny) W środowiskach produkcyjnych powinno się uzyskać certyfik podpisany przez odpowiednią instytucję. W celu uzyskania podpisanego certyfiku należy najpierw wygenerować żądanie podpisania certyfiku (ang. certifice signing request). W przykładzie wywołania odpowiedniej komendy żądanie to ma zostać zapisane w pliku tkubikcert.csr: $ keytool -certreq -alias tkubik -keystore tkubikkeys.jks > tkubikcert.csr Po przesłaniu żądania do instytucji certyfikującej i otrzymaniu odpowiedzi z podpisanym certyfikem należałoby go zaimportować do repozytorium kluczy. W przykładzie odpowiedniej komendy podpisany certyfik znajduje się w pliku tkubikcert.pem: $ keytool -import -alias tkubik -file tkubikcert.pem -keystore tkubikkeys.jks Wykonanie powyższej komendy spowoduje nadpisanie niepodpisanego certyfiku znajdującego się w magazynie kluczy. Wystawianie (i utrzymywanie) certyfików odbywa się za opłą. Do testowania nie potrzeba zabiegać o podpisanie samodzielnie wygenerowanego certyfiku. 4. Wyeksportowanie certyfiku z kluczem publicznym Podpisana bibliteka (plik jar) powinna być dystrybuowana razem z certyfikem zawierającym klucz publiczny. Bez niego klienci korzystający z biblioteki nie będą w stanie zweryfikować poprawności jej podpisu. Aby wyeksportować klucz publiczny należy wydać następującą komendę: $ keytool -export -keystore tkubikkeys.jks -alias tkubik -file tkubik_pub.cer Klucz publiczny zostanie wyeksportowany do pliku tkubik_pub.cer, który powinien towarzyszyć dystrubuowanemu plikowi jar. Klienci korzystający z biblioteki będą importować ten certyfik do własnego magazynu kluczy. 5. Podpisanie pliku jar Podpisanie biblioteki może odbyć się za pomocą narzędzia jarsigner: $ jarsigner -keystore tkubikkeys.jks -storepass <hasło magazynu> - keypass <hasło klucza prywnego> -signedjar sbilioteka01.jar biblioteka01.jar tkubik gdzie: biblioteka01.jar - oryginalna biblioteka (niepodpisana), sbiblioteka01.jar - wynikowa biblioteka (podpisana), tkubik - alias wpisu w magazynie kluczy (by było wiadomo, jakim certyfikem podpisać bibliotekę)

3 Przy okazji można zweryfikować, czy faktycznie plik jar został podpisany komendą: $ jarsigner -verify -certs -verbose sbiblioteka01.jar W rozważanym przykładzie wynikiem wykonania komendy będzie: s 196 Wed May 08 18:30:32 CEST 2019 META-INF/MANIFEST.MF X.509, CN=Tomasz Kubik [certifice will expire on :10] [CertPh not valided: Ph does not chain with any of the trust anchors ] 332 Wed May 08 18:30:32 CEST 2019 META-INF/TKUBIK.SF 1115 Wed May 08 18:30:32 CEST 2019 META-INF/TKUBIK.RSA sm 3229 Wed May 08 17:36:40 CEST 2019 pl/edu/pwr/example/encoder.class X.509, CN=Tomasz Kubik [certifice will expire on :10] [CertPh not valided: Ph does not chain with any of the trust anchors ] s = signure was verified m = entry is listed in manifest k = least one certifice was found in keystore i = least one certifice was found in identity scope - Signed by "CN=Tomasz Kubik" Digest algorithm: SHA-256 Signure algorithm: SHA256withRSA, 2048-bit key jar verified. Warning: This jar contains entries whose certifice chain is not valided. This jar contains entries whose signer certifice will expire within six months. This jar contains signures th does not include a timestamp. Without a timest amp, users may not be able to valide this jar after the signer certifice's e xpirion de ( ) or after any future revocion de. 6. Wykorzystanie podpisanej biblioteki Ktoś, kto chciałby skorzystać z podpisanej biblioteki powinien dołączyć ją do projektu. Samo dołączenie do projektu pozwala kompilować kod. Dopóki nie ma zdefiniowanego menadżera bezpbieczeństwa, to ten kod daje się również wykonywać. Ale nie zawsze. Jeśli dana biblioteka (podpisany jar) ma takie same pakiety jak aplikacja, która z niej korzysta, to przy próbie uruchomienia pojawia się wyjątek bezpieczeństwa:

4 Exception in thread "main" java.lang.securityexception: class "pl.edu.pwr.example.encoder"'s signer informion does not mch signer informion of other classes in the same package java.base/java.lang.classloader.checkcerts(classloader.java:1150) java.base/java.lang.classloader.predefineclass(classloader.java:905) java.base/java.lang.classloader.defineclass(classloader.java:1014) java.base/java.security.secureclassloader.defineclass(secureclassloa der.java:174) java.base/jdk.internal.loader.builtinclassloader.defineclass(builtin ClassLoader.java:802) java.base/jdk.internal.loader.builtinclassloader.findclassonclassp hornull(builtinclassloader.java:700) java.base/jdk.internal.loader.builtinclassloader.loadclassornull(bui ltinclassloader.java:623) java.base/jdk.internal.loader.builtinclassloader.loadclass(builtincl assloader.java:581) java.base/jdk.internal.loader.classloaders$appclassloader.loadclass( ClassLoaders.java:178) java.base/java.lang.classloader.loadclass(classloader.java:521) pl.edu.pwr.example.main.main(main.java:30) W przypadku różnych nazw pakietów w bibliotece i aplikacji żaden wyjątek się nie pojawi - dopóki nie zostanie zainstalowany menadżer bezpieczeństwa. Jeśli aplikacja korzysta z menadżera bezpieczeństwa, to by wszystko zadziałało należy podjąć kolejne kroki. Na początek należy zaimportować certyfik towarzyszący podpisanej bibliotece do własnego magazynu kluczy. Oczywiście jeśli podpisana bibliotaka jest testowana na komputerze jej autora, nie trzeba importować certyfiku do magazynu - w tym magazynie jest już przecież certyfik (z niego był eksportowany). Następnie należy zdefiniować pozwolenia w pliku polityki. Przykładowo plik taki może mieć postać: /* AUTOMATICALLY GENERATED ON Thu May 09 00:53:26 CEST 2019*/ /* DO NOT EDIT */ keystore "file:/e:/.../tkubikkeys.jks", "JKS", "SUN"; keystorepasswordurl "file:/e:/.../keystore.pass"; grant signedby "tkubik", codebase "file:../sbiblioteka01.jar" { permission java.security.allpermission;

5 permission java.io.filepermission "<<ALL FILES>>", "read, write, delete, execute"; Inny przykład (z wykorzystaniem właściwości systemowych, pochodzący ze strony: content.html) keystore "${user.home}${/}.keystore"; grant codebase " { permission java.io.filepermission "/tmp", "read"; permission java.lang.runtimepermission "queueprintjob"; grant signedby "edek", codebase "file:${java.home}/lib/ext/." { permission java.security.allpermission; grant signedby "edek", codebase "file:${java.class.ph}/." { permission java.net.socketpermission "*:1024-", "accept, connect, listen, resolve"; grant { permission java.util.permission "java.version", "read"; Uwaga: W pliku keystore.pass wskazanym przez w urlu powinna pojawić się linijka z hasłem do magazynu kluczy użytkownika, do którego zaimportowano certyfik z publicznym kluczem (prz niżej). Plik ten można sobie nazwać dowolnie i umieścić w kalogu dostępnym tylko dla użytkownika. Pliki polityki można generować ręcznie, ale nieźle sprawuje się tu też narzędzie $ policytool.exe Jeśli ktoś zapomniał aliasu do certyfiku, to można go odszukać przeglądając magazyn: $ keytool -list -v -keystore [keystore name] W szczególności certyfik można zaimportować do magazynu zaufanych certyfików: $ keytool -import -trustcacerts -keystore [keystore_filename] -alias [alias_name] -file [cert_file] Po tym wszystkim można już uruchomić program z odpowiednimi parametrami, najlepiej w kalogu projektu aplikacji (w przykładzie jest to główny kalog projektu Aplikacja01). W parametrach przekazuje się menadżera bezpieczeństwa, położenie pliku polityki oraz wskazuje classph: $ java -Djava.security.manager -Djava.security.policy=tkubik.policy -classph "./bin;../sbilioteka01.jar" pl.edu.pwr.example1.main Oczywiście parametry te można wpisać w konfigurację uruchomieniową wybranego IDE.

6 Próba uruchomienia aplikacji z menadżerem bezpieczeństwa bez wskazania położenia pliku polityki zakończy się wyrzuceniem wyjątku: Exception in thread "main" java.security.accesscontrolexception: access denied ("java.io.filepermission" "logfilein.txt" "write") java.base/java.security.accesscontrolcontext.checkpermission(accessc ontrolcontext.java:472) java.base/java.security.accesscontroller.checkpermission(accesscontr oller.java:895) java.base/java.lang.securitymanager.checkpermission(securitymanager. java:322) java.base/java.lang.securitymanager.checkwrite(securitymanager.java: 752) java.base/sun.nio.fs.windowschannelfactory.open(windowschannelfactor y.java:301) java.base/sun.nio.fs.windowschannelfactory.newfilechannel(windowscha nnelfactory.java:168) java.base/sun.nio.fs.windowsfilesystemprovider.newbytechannel(window sfilesystemprovider.java:226) java.base/java.nio.file.spi.filesystemprovider.newoutputstream(files ystemprovider.java:478) java.base/java.nio.file.files.newoutputstream(files.java:219) pl.edu.pwr.example1.main.main(main.java:26) Ciekawostki: symlink (chodzi o to, że przy kilku wersjach JDK zainstalowanych na jednym komputerze wydawanie komend java z konsoli może być kłopotliwe ze względu na istnienie sybmolicznych linków w ścieżce systemowej: C:\ProgramDa\Oracle\Java\javaph)

7 JShell (shell do testowania fragmentów kodu java) keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize tml#importcmd trukcja_podpisywania_kodu_przy_uzyciu_narzedzi_signtool_i_jarsigner. pdf Co należy zrobić, gdy zostanie wyświetlony monit zabezpieczeń oprogramowania Java? Java SE Security Meriały: html Java Plform Standard Edition 8 Documention tml#importcmd Permission policy file

8 Jar signing in Maven Podpisywanie kodu Java: Generowanie żądania CSR