en:esya:sertifika:dogrulama-kutuphane
Farklar
Bu sayfanın seçili sürümü ile mevcut sürümü arasındaki farkları gösterir.
|
en:esya:sertifika:dogrulama-kutuphane [2013/08/23 10:57] Dindar Öz |
en:esya:sertifika:dogrulama-kutuphane [2013/08/23 12:49] (mevcut) Dindar Öz |
||
|---|---|---|---|
| Satır 82: | Satır 82: | ||
| ===== Matchers ===== | ===== Matchers ===== | ||
| - | The certificates, crs and OCSP responses that Finders have found, must be matched according to certain criteria in order to guarantee that they are the correct ones. Matchers perform these matching operations according to the rules defined in RFC 5280. Matcher classes are organized as follows: | + | The certificates, crls and OCSP responses that Finders have found, must be matched according to certain criteria in order to guarantee that they are the correct ones. Matchers perform these matching operations according to the rules defined in RFC 5280. Matcher classes are organized as follows: |
| ==== Certificate Matchers ==== | ==== Certificate Matchers ==== | ||
| - | Sertifika ile yayıncı sertifikasını eşleştiren sınıflardır. Örneğin RFC 5280'de bir X509 sertifikası üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Esya Sertifika Doğrulama kütüphanesinde bu eşleştirme işini gerçekleştiren eşleştirici (IssuerSubjectMatcher) sınıfı vardır. Eşleştiricilerin eşleştiremediği sertifikalar yayıncı sertifikası olarak sertifika zincirine eklenmezler. | + | Certificate matchers decides if a certificate and an issuer certificate are related with issuer-subject relation. For example, RFC 5280 states that the issuer filed in the certificate must be the same as the subject field in the issuer certificate. In the Validation API, there is a certificate matcher class , named IssuerSubjectMatcher, that checks this relation between a certificate and an issuer certificate. Issuer certificates are not added to the certificate chain if they are not matched by the certificate matchers defined in the validation policy. |
| ==== CRL Matchers ==== | ==== CRL Matchers ==== | ||
| - | Sertifika ile SİL'i ya da SİL ile SİL yayınlayan sertifikayı eşleştiren sınıflardır. Örneğin RFC 5280'de , dolaylı SİL (indirect crl) kullanılmıyorsa, bir SİL üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Bir SİL'in yayıncı sertifikası olan sertifikanın bulunması için bu ifadenin doğruluğu kontrol edilir. Bu kontrol işlemi için bir eşleştirici (CRLIssuerMatcher) tanımlıdır. | + | CRL matchers decides if a certificate matches with the crl found by CRL Finders. For example RFC 5280 states that unless indirec crl is being used, the issuer field in the crl must matched with the issuer field in the certificate for which the crl is published. In the Validation API, there is a crl matcher class , named CRLIssuerMatcher, that checks this relation between a certificate and a crl. CRLs are not used in revocation control of a certificate if they are not matched by the crl matcher classes defined in the validation policy. |
| ==== OCSP Response Matchers ==== | ==== OCSP Response Matchers ==== | ||
| - | Sertifika ile OCSP cevabını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir | + | OCSP Response matchers decides if a certificate matches with the OCSP Response found by OCSP Response Finders. |
| + | The basic operational logic is very similar to certificate and crl matchers. | ||
| ==== Delta CRL Matchers ==== | ==== Delta CRL Matchers ==== | ||
| - | SİL ile Delta-SİL'i eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir | + | Delta CRL matchers decides if a base CRL matches with the delta CRL found by Delta CRL Finders. |
| + | The basic operational logic is very similar to certificate and crl matchers. | ||
| ==== Cross Certificate Matchers ==== | ==== Cross Certificate Matchers ==== | ||
| - | SM Sertifikası ile çapraz SM sertifikasını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir. | + | Cross Certificate matchers decides if a CA certificate matches with another CA certificate found by certificate finders. The basic operational logic is very similar to certificate and crl matchers.. |
| - | Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm eşleştiricilerin listesi [[esya:sertifika:dogrulama-politikası|Table 2’de]] yer almaktadır. | + | Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm eşleştiricilerin listesi [[en:esya:sertifika:dogrulama-politikası|Table 2]] yer almaktadır. |
| ===== Savers ===== | ===== Savers ===== | ||
| - | Esya Sertifika Doğrulama API'si doğrulama sırasında bulduğu sertifika ve SİL'leri yerel depoya kaydeder. Bu işlemi kaydediciler (Saver) gerçekleştirir ve yine politika dosyası aracılığıyla hangi kaydedicilerin çalışacağı tanımlanabilir. Örneğin istenildiği kadar kaydedici tanımlanarak doğrulama sırasında bulunan ve doğrulanan bütün sertifikalar istenilen yerlere kaydedilirler. | + | ESYA Certificate Validation API saves the certificates and CRL's found during validation to the local certificate store. Savers are responsible for this operation. The list of savers can be specified by the validation policy file. |
| - | Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm kaydedicilerin listesi [[esya:sertifika:dogrulama-politikası|Table 4’te]] yer almaktadır. | + | The list of all savers defined in ESYA Certificate Validation API is shown in [[en:esya:sertifika:dogrulama-politikası| Table 4]] |
| ===== Certificate Validation Policy ===== | ===== Certificate Validation Policy ===== | ||
| - | Sertifika doğrulama işlemi bir çok kontrol işleminin arka arkaya yapılmasından oluşan bir süreçtir. Bu kontrol işlemlerinin hangilerinin yapılıp hangilerinin yapılmayacağını ve bu kontroller sırasında kullanılan bir takım parametrelerin çalışma zamanında belirlenebilmesi için XML formatında bir doğrulama politikası dosyası kullanılmaktadır. Bu XML dosyasında yer alan her bir “class” elemanı bir sınıfı temsil eder ve bu sınıflar doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıflarıdır. Bu dosya, doğrulama işleminin başında okunarak doğrulama politikası nesnesi oluşur ve bütün doğrulama adımları bu politikada belirtilen yapılandırma bilgileri doğrultusunda gerçekleştirilir. Doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıfları, sertifika politikası kontrolleri ile ilgili ayarlar bu yapılandırma bilgilerinden bazılarıdır. | + | Certificate validation is series of sequentially performed control steps. The list of controls steps to be performed, and some other validation parameters can be defined at run-time via an XML-based file, named as certificate validation policy file. In this file, every element named as "class" represents a class in the Certificate Validation API which is a Checker, Finder, Matcher, or Saver class. At the beginning of the validation operation, the policy file is read and policy object is created. The whole validation process is performed according the configuration information defined by this policy object. |
| A sample validation policy | A sample validation policy | ||
| Satır 239: | Satır 243: | ||
| ==== Security Issues Concerning Certificate Validation Policy File ==== | ==== Security Issues Concerning Certificate Validation Policy File ==== | ||
| - | Politika dosyası, sertifika doğrulama sırasında kullanılacak verilerin nasıl bulunacağını (find), doğru verilerin bulunup bulunmadığının kontrolü için nasıl eşleştirme yapılacağını (match) ve doğrulama sırasında hangi kontrollerin yapılacağını (validate) belirten sınıfları bulunduran dosyadır. | + | Policy file specifies the control steps, location and the find method of external resources, and matching criteria for those resources.Furthermore, the trusted certificates that the certificate chains must end at are also defined by certificate validation policy. Therefore it is crucial that the policy file can not be modified in an unauthorized manner. Malicious people can cause verification of signed documents which are created by invalid certificates by changing the certificate validation policy file. For the security of the policy file the measures below can be taken; |
| - | Politika dosyasının değiştirilememesi imza doğrulama için hayati önem taşır. Politika dosyasında hangi kontrollerin yapılacağı ve hangi sertifikalara güvenileceği bilgisi yer almaktadır. Kötü niyetli kişiler politika dosyasını değiştirerek, kötü niyetle yaratılmış imzaların doğrulanmasını sağlayabilirler. | + | * The Policy file is retrieved from a server and stored in the memory. Thus, unauthorized access to the policy file gets more difficult. |
| - | Politika dosyası için aşağıdaki güvenlik önlemleri uygulanabilir; | + | * The hash of the policy file stored at the server-side. Upon verification at the client-side, first the hash of the policy file is calculated and matched with the one at the server-side. This prevents unauthorized modification of the policy file. Hash calculation can be performed by DigestUtil class. |
| + | * The Policy file is stored as password-based encrypted and decrypted in memory whenever it is used for certificate validation. | ||
| + | * The policy file can is signed and verified whenever it is used for certificate validation.For the verification of the signature of the policy file, the signing certificate must be embedded into the source code of your application. Since it is very hard to change the embedded certificate in the source code, you have to take great care for not losing the private keys corresponding to the certificate used for signing the policy file. You can use PKCS7 signatures ([[en:esya:smartcard:pkcs7|see pkcs7]]) | ||
| - | * Politika dosyası sunucudan çekilir ve bellekte tutulur. Böylelikle politika dosyasına dışardan müdahale olasılığı azalır. | + | We certainly recommend taking one or more precautions listed above for your security. |
| - | * Politika dosyasının özeti sunucuda tutulur. İstemcideki politika dosyasının özeti alınır ve sunucudan çekilen özet ile karşılaştırılır. DigestUtil sınıfı ile özet işlemini gerçekleştirebilirsiniz. | + | |
| - | * Politika dosyası istemcide parola tabanlı şifrelenerek tutulur ve şifresi bellekte çözülür. Bunun nasıl yapıldığı gösteren örneği "http://www.java2s.com/Tutorial/Java/0490Security/PBEFileEncrypt.htm" adresinde bulabilirsiniz. | + | |
| - | * Politika dosyası imzalı bir şekilde tutulur. Politika dosyasına karar verildikten sonra politika dosyası bir kere imzalanır ve bu imzalı dosya istemcilerde tutulur. İmzalanan politika dosyasının imzası doğrulanırsa ve imza doğru kişi tarafından atılmışsa; politika dosyasına güvenilebilir. Doğru kişi imzalamış mı kontrolünün yapılması için, kodunuzun içine imzacı sertifikasının gömülmesi gerekmektedir. Kodunuzu, devamlı değiştiremeyeceğinizden imzalama işleminde kullandığınız akıllı kartı veya pfx dosyasını kesinlikle kaybetmemeniz gerekmektedir. Politika dosyasını PKCS7 standardında imzalayabilirsiniz. PKCS7 tipindeki imza için [[esya:smartcard:pkcs7|buraya]] bakabilirsiniz. | + | |
| - | + | ||
| - | Yukarıdaki güvenlik önlemleri birlikte veya tek olarak uygulanabilir. Politika dosyasının güvensiz bir şekilde istemcilerde durmasını kesinlikle önermiyoruz. | + | |
| ==== Certificate/CRL Status Info ==== | ==== Certificate/CRL Status Info ==== | ||
| - | Esya Sertifika Doğrulama Kütüphanesi sertifika ve SİL doğrulama işlemi sonucunda Sertifika Durum Bilgisi (CertificateStatusInfo) ve SİL Durum Bilgisi (CRLStatusInfo) sınıflarından bir nesne oluşturur. Bu sınıf içerisinde ayrıntılı kontrol detayları , oluşturulmuş ve doğrulanmaya çalışılan farklı sertifika zincirleri doğrulanma sonuçlarıyla birlikte detaylı olarak saklanır. Bu sınıfın nesnesinin kullanımı, örnek kodlarla birlikte [[esya:cades:eimza-cades-kutuphanesi|CAdES İmza Kütüphanesi]] bölümünde daha detaylı olarak görülebilir. | + | ESYA Certificate Validation API creates an object of CertificateStatusInfo or CRLStatusInfo classes after the validation of certificate or crl accordingly. In this object, detailed validation information such as invalid certificate chains found during validation can be found. The usage of CertificateStatusInfo and CRLStatusInfo classes with sample codes can be found in [[en:esya:cades:eimza-cades-kutuphanesi|CAdES Signature API]] |
| ===== Local Certificate Store ===== | ===== Local Certificate Store ===== | ||
| - | Sertifika deposu, güvenilir olduğu kabul edilen yayıncı sertifikalarının saklanabileceği bir kök sertifika deposu olarak geliştirilmiştir. | + | Certificate Store is a file-based database and designed as a storage for the certificates of the trusted issuers. It also plays a cache role for the issuer certificates, crls and OCSP Responses in the certificate validation process. Once those resources are retrieved from a remote source then they are stored in the local certificate store and used upon further demand by other validation operations. |
| - | Sertifika deposu aynı zamanda doğrulama işlemi sırasında bulunması gereken yayıncı sertifikası, SİL, OCSP cevabı gibi verilerin sürekli uzak kaynaklardan çekilmesini engellemek için bu verilerin yerelde saklanabilmesinden sorumludur. | + | The default location of the certificate store, is the ".sertifikadeposu" folder located in the user's home directory. The default name for the certificate store file is "SertifikaDeposu.svt". If a different name and location is used for the certificate store then these parameters must be defined in the certificate validation policy file by specifying the parameter named as "storepath". |
| - | Sertifika deposunun varsayılan yeri, kullanıcının ana klasörünün(user home directory) altındaki ".sertifikadeposu" klasörünün içidir. Varsayılan dosya ismi ise "SertifikaDeposu.svt"dir. Eğer farklı bir dosya yolu ve dosya ismi kullanılması isteniyorsa, sertifika doğrulama politika dosyasında belirtilmelidir. Bunun için storepath parametresi kullanılmalıdır. | + | ESYA Certificate Validation API trusts the certificates that are defined as trusted rood certificates in the certificate store. |
| - | + | ||
| - | Esya Sertifika Doğrulama API'si yerel sertifika deposunda güvenilir kök sertifikası olarak tanımlanmış seritikaları güvenilir olarak kabul eder ve doğrulama sırasında oluşturduğu sertifika zincirlerinin bu sertifikalardan biriyle sonlanmasını bekler. API'deki yerel sertifika deposundan sertifika ve sil bulucular kullanılarak doğrulama verileri istenildiğinde yerel depodan bulunabilir. | + | |
| <sxh xml> | <sxh xml> | ||
| Satır 271: | Satır 270: | ||
| </sxh> | </sxh> | ||
| - | Test sertifikalarıyla çalışırken sertifikanın doğrulanması sırasında PATH_VALIDATION_FAILURE hatası alabilirsiniz. Bu durumun muhtemel sebebi, test sertifikaların köklerinin sertifika deposunda güvenilir sertifika olarak tanımlanmamasıdır. Bu kök sertifikaları dosya yoluyla belirtebilirsiniz. Yalnız bu kullanım sadece test amacıyla yapılmalıdır. | + | You can have PATH_VALIDATION_FAILURE error during the validation of the test certificates.Most probably the reason is that the issuer of the test certificates is not defined as trusted root in your certificate store. |
| + | You can make this issuer certificates trusted by te API by using TrustedCertificateFinderFromFile class, which is only recommended for testing purposes. | ||
| + | |||
| <sxh xml> | <sxh xml> | ||
| <class name="("tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem"> | <class name="("tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem"> | ||
| Satır 279: | Satır 279: | ||
| </sxh> | </sxh> | ||
| - | ===== XML Sertifika Deposu ===== | + | ===== XML Certificate Store ===== |
| - | Dosya sistemine herhangi bir şekilde erişimin olmadığı durumlarda kullanılması için XML tabanlı sertifika deposu dosyası geliştirilmiştir. Bu şekilde internet üzerindeki bir depo ile çalışabilmek mümkün olmaktadır. | + | In cases, where the usage of file-based certificate store is not available, an XML-based certificate store is created. Thus, you can work with a certificate store that is located on Internet. |
| - | Sertifika doğrulama konfigürasyon dosyasında XML depodan güvenilir sertifika bulucu aşağıdaki gibi tanımlanır: | + | In the certificate validation policy file, you can define the trusted certificate finder class finding trusted certificates from an XML certificate store as follows: |
| <sxh xml> | <sxh xml> | ||
| Satır 289: | Satır 289: | ||
| <param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> | <param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> | ||
| </class> | </class> | ||
| - | Yine xml depodan sertifika bulucu aşağıdaki şekilde tanımlanır: | + | |
| + | A certificate finder from an XML store is also defined as follows: | ||
| <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromXml"> | <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromXml"> | ||
| <param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> | <param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> | ||
| Satır 295: | Satır 296: | ||
| </sxh> | </sxh> | ||
| - | XML depodan güvenilir sertifika bulucu parametre olarak bir URL almaktadır. Performans arttırmak için yerel ağlarda bu dosyanın bir kopyasını bulundurmak ve onunla çalışmak faydalı olur. | + | TrustedCertificateFinderFromXml takes a URL parameter for the location of the XML store.To increase the performance locating the XML store on the local network should be pereferred if possible. |
| - | Bunun yanında xml sertifika deposu sadece ESYA sertifika doğrulama kütüphanesi ile kullanılmalıdır. Aksi taktirde man-in-the-midle saldırısına kapı açılmış olur. ESYA Kütüphanesi bu dosyadaki güvenilir sertifikalar için imza kontrolü yapmaktadır. | + | Besides, XML certificate store must only be used with ESYA Certificate Validation API, which performs signature verification on the trusted certificates. Otherwise, you can not be sure that the store is not altered by any man-in-the-middle attack. |
| - | Bir diğer göz önünde bulundurulması gereken konu performanstır. Yerel sertifika deposu kullanılırken imza doğrulamada kullanılan iptal listeleri depoya kaydedilip tekrar kullanılabilirken, xml sertifika deposu sadece okuma özellikli olduğu için bu avantajdan mahrumdur. Bu yüzden iptal listeleri her doğrulamada tekrar indirilmek zorunda kalınacaktır. Bu da ciddi performans kaybına yol açar. | + | One more thing to be mentioned is about the performance degradation caused by using XML store instead of local certificate store. This happens because you can not save the CRL files found at remote location during certificate validation if you are using XML store as XML store is a read-only source. Thus, you must repeatedly retrieve the same crls from remote locations whenever they are needed. |
en/esya/sertifika/dogrulama-kutuphane.1377255431.txt.gz · Son değiştirilme: 2013/08/23 10:57 Değiştiren: Dindar Öz
Aksi belirtilmediği halde, bu wikinin içeriğinin telif hakları şu lisans ile korunmaktadır: CC Attribution-Share Alike 3.0 Unported
