Açık Anahtar Altyapısı ve Problemleri

Transkript

1 Açık Anahtar Altyapısı ve Problemleri Hasan GENÇ Gebze Yüksek Teknoloji Enstitüsü, Bilgisayar Mühendisliği Bölümü, Kocaeli Özet: Açık Anahtar Altyapısı(AAA) sistemlerini meydana getiren elemanlar ve standartlardaki problemlerden bahsedilmiştir. AAA internet kullanıcıları arasında eletronik ticarete ve güvenli haberleşmesine izin verir. AAA nın kullanımı için bir çok standart ve geçici çözümler geliştirilmiştir. Bunlardan biri olan X509 orjinalde X500 dizin sistemine erişim problemini çözmek geliştirilmiştir ve temel problemlerin çözümünü sağlamamaktadır. Üreticiler problemleri çözmek için farklı yöntemler geliştirdiklerini görürüz. Örneğin SPKI/PGP kendi yaklaşımlarıyla X509 daki isimlerdirme problemini çözmüştür. Bir diğer örnekte, son olarak iptal listelerinin onaylaması için önerilen OCSP, online olarak iptal listelerinin sorgulanmasını sağlayan bir yapı sağlar. Fakat bu çözümler bütün problemlerin çözülmesi için yeterli değildir 1. Sunuş Açık Anahtar tabanlı sistemler günümüz internet ortamında e-ticaret ve iletişimin güvenlik ihtiyacının karşılanması konusunda herkesin hem fikir olduğu bir çözümdür. Fakat standart olarak kabul edilen X509 tabanlı Açık Anahtar Altyapısı(AAA) nda belirtilen altyapı yani sistemin altyapısındaki problemler AAA nın çözüm olarak kullanılmasını zorlaştırmaktadır. Bu nedenle üretici firmalar kendi ihtiyaçlarını karşılayan daha ekonomik ve daha kullanışlı açık anahtar yapısı geliştirmektedirler. X509 temelde X500 dizin sistemine erişim kontrollerini çözmek için geliştirilmiştir. Doğal olarak X509, X500/LDAP dizinlerine, hiyerarşi yapılarına, offline iptal ve X500 den gelen diğer yapılara bağlıdır. Bugün kullanılan teknik ve metotlarda ilişkisel veritabanları, hiyerarşi bulunmayan organizasyonlar, online doğrulama ve yetkilerin kontrolü gibi yeni teknolojik yapıların ihitiyaçlarını karşılamak zorundadır. Bu raporda AAA daki altyapı problemleri ve geliştirilen çözümler hakkında bahsedilecektir.

2 2. Açık Anahtar Altyapısı Elemanları AAA, bir ağ ortamında açık anahtar kripto sisteminin kullanımına izin veren servislerden oluşur. AAA nın başlıca görevi açık anahtarların sahipleri olan varlıklar için dijital sertifikaların üretilmesi, yayınlanması ve yönetimini sağlamaktır. AAA temel güvenlik gerekleri olan gizlilik, bütünlük, süreklilik ve inkar edemezlik gibi son kullanıcı ihtiyaçlarını karşılar. Bu güvenlik servisleri mesajları şifreleyip ve imzalayan anahtarların kullanımına bağlıdır. Güvenlik ihtiyacı ilk önce gizli anahtarların gizliliği ve açık anahtarların güvenli bir şekilde ulaştırılıp ve depolanmasıdır. Küçük bir alanda, açık anahtarların güvenli ve emin bir şekilde ulaştırılması mümkündür. Fakat uluslar arası bir mesajlaşma ortamında kullanıcılar arasında anahtarların ulaştırılması pratik değildir. Bunun için güvenilir üçüncü taraflar tarafından uygulanan otomatik anahtar yönetimi ve dijital imzalara ihtiyaç vardır. AAA yapısında bulunan temel elemanlar; Kayıt İşlemi (Registration) : Bir AAA ortamına kullanıcıların katılıp kullanmaları için AAA sistemine ait güvenilir üçüncü şahıs servisine kayıt olmaları gerekir. Çünkü kullanıcı ile açık anahtarı arasındaki bağlantıyı sağlayacak fonksiyon servislerini sağlar. Bu servis içinde isteklerin gönderilmesi, güvenilir üçüncü şahısların yerine kayıt formlarını ve son kullanıcının kimliğinin doğruluğunu onaylar. Dijital imzalar (Digital Signatures) : Mesajların doğrulanması, bütünlüğü ve inkar edemezlik gibi ihtiyaçları karşılayan AAA servisidir. Bu servis ile mesajların özetinin çıkarılması (hash generation) ve mesajların özet şifreleme/deşifreleme (hash encryption/decryption) gibi fonksiyonları bulunur. Şifreleme (Encryption) : Bir ağ ortamında mesajların gizliliğini sağlayarak koruma sağlayan kripto fonksiyonlarından oluşur. Zaman Pulu (Time-stamping) : Veri ve dokümanlara eklenen zaman pulu ile geçerli olduğu zamanı aralığını belirler. Bu fonksiyonları içeren servis içinde, zaman pulu istekleri, zaman pulu sertifikalarının doğrulanması, depolanması ve üretilmesi gibi fonksiyonlar bulunur. İnkar Edemezlik (Non-repudiation) : Verilerin işlenmesi, toplanması, tekrar elde edilmesi ve doğruluğunun onaylanması gibi işlemleri içerir. Bu işlemler bağımsız üçüncü taraflar tarafından gerçekleştirilir ve oluşturma, iptal etme, karışıkların çözümü ve onaylama gibi işlemlerden oluşur. Anahtar Yönetimi (Key Management) : AAA nın en önemli servislerindendir. Bu servis kripto anahtarlarının güvenli, ölçeklenebilir ve güvenli olarak tutulmasından sorumludur. Bu servis içinde anahtarların üretimi, anahtarların sahiplendirilmesi, dağıtılması, depolanması, geri alınması, yedeklenmesi, güncellenmesi, anahtar erişim isteklerinin doğrulanması ve yönetim fonksiyonlarından oluşur.

3 Yönetimi (Certificate Management) : Dijital sertifikalar bir varlık ile onun açık anahtarı arasındaki ilişkiyi sağlayan bir elektronik bilet olarak düşünülebilir. Bu servis içinde sertifikaların üretimi, dağıtımı, depolanması, geri alınması ve iptali gibi fonksiyonları bulunur. Dizin Servisleri (Directory Services) : AAA daki kullanıcılarının diğer kullanıcılar hakkında bilgi almak için kullandığı fonksiyonları içerir. Bunun içinde yeni sertifikaların güncellenmesi, iptal sertifikalarının güncellenmesi, dağıtım, yedekleme, arama, sertifika isteklerinin karşılanması gibi fonksiyonlar bulunur. Yetkilendirme (Authorization) : AAA daki bir varlık haklarının bir kısmını diğer bir varlığa vermek isteyebilir. Yani bir kaynağa erişen varlığın diğer bir varlığında aynı kaynağa erişmesini isteyebilir. Bunun için güvenilir üçüncü şahıslar belirli kaynaklar üzerindeki hakların verilmesinden emin olmalıdır. Bu servis içinde doğrulama, grup tanımlanması, hakların güncellenmesi, kullanıcıların gruba eklenmesi, hakların çözümlenmesi ve yönetim yetkilerinin belirlenmesi gibi fonksiyonları içerir. Güvenlik Politikaları ve CPS(Certificate Practice Statements) : AAA da güvenlik politikası AAA içindeki elemanların uygulaması gereken kuralların bir kümesidir. Kurallar kullanıcılar tarafından nasıl uygulanacağı bilgisini içerir. Bu kurallar yetkili kullanıcılar tarafından oluşturulan dijital imzalı dokümanlardır. Bir AAA politikası seri numarası, yayın tarihi, gelecek yayın tarihi ve politika elemanlarının kümesinden oluşur. Politikanın bütünlüğü sağlamak ve kullanıcısını onaylamak için dijital olarak imzalanır. İmzalar yöneticinin gizli anahtarı kullanılarak veya tarafından direk olarak oluşturulur. X509 sertifikalarında AAA daki politikaların yayınlanması için yetki bilgilerini içeren bir bilgi yoktur, bunun için sadece güvenli kanalar üzerinden gelen politikalar onaylanmalıdır. Aksi halde yetkisiz kullanıcılar kolaylıkla alternatif politikaları imzalayıp yayınlayabilir. tarafından üretilen politikalar büyük, kompleks ve dinamik ortamlar için en iyi alternatiftir. Kök tarafından imzalanan politikalar bütün AAA sistemi içindeki bütün varlıklar tarafından kolaylıkla onaylanabilir. AAA daki lar için IETF/PKIX ve EESSI programı içinde CPS(Certificate Practice Statements) geliştirmektedir. CPS sertifikaların yaşam çevrimini yöneten ların politikalarını belirler. Kuralları birkaç guruba ayırırsak; - Kuralları: Bu kurallar sertifika isteği içinde bulunan geçerlilik süresi, anahtar tipi, anahtar uzunluğu, sertifika eklentileri ve alternatif isimler gibi bazı alanların kontrolünü sağlar. Kullanıcıların sertifika isteklerini onaylamak için, bu kurallar Kayıt Otoriteleri (KO-Registration Authorities) tarafından uygulanır. tarafından uygulanan sertifika ile ilgili diğer kurallar OCSP sunucusu veya CPS adres bilgilerini içeren eklentilerdir.

4 - Tekrar-Yayın Kuralları: Bu kurallar sertifikaların kullanımının ne zaman sona ereceğini belirler. Kurallar sertifikanın tekrar yayınlanıp yayınlanmayacağı ve gelecek yayın tarihini kontrol eder. Bu kuralların uygulanmasında Kayıt Otoriteleri sorumludur. - İptal Kuralları: Bir anahtarın ihlali gibi durumlarda özellikle nun iptal işlemini nasıl yapılacağını belirleyen kurallardır. Örneğin sertifikası iptal edildiğinde ve yeni sertifikası yayınlandığında daha önce geçerli olan bütün sertifikaların tekrar otomatik olarak yayınlanmasını zorlar. CIM Nesne Yöneticisi Politika Yönetim Araçları (Parser XML/LDAP) yükleme/ okuma LDAP Politika Deposu CIM-XML CIM istemcisi Yönetici Şekil 1 Genel Bilgi Modeli(Common Information Model) Büyük bir ağ ortamında elemanların yönetilebilirliği için politika tabanlı yönetim sistemleri geliştirilmiştir. Güvenlik politikalarının yönetimi de ağ yönetim sistemlerini bir parçasıdır. DMTF(Distributed Management Task Force) tarafından dağıtık sistemlerin iletişiminin yönetilmesi için standartlar geliştirilmiştir. Farklı güvenlik bölgelerinin güvenlik politikalarının yönetilmesinde de kullanılır. LDAP Politika Deposu okuma Politika Karar Noktası COPS bulunmayan IPSec düğümü COPS okuma COPS IPSec Düğümü uygulama 3 Politika Uygulama Noktası politika uygulaması SNMP (MIB) Güvenlik Politikası Veritabanı uygulama 1 COPS bulunmayan IPSec düğümü (SNMP ajanı) uygulama 2 Şekil 2 Genel Açık Politika Modeli(Common Open Policy Model)

5 DMTF tarafından tanımlı bu modelde (Genel Bilgi Modeli-CIM-Common Information Model) herhangi bir ağ ortamı için ( SNMP de dahil ) yönetim bilgilerini açıklayan ortak veri şeması sağlar.[5,7] (Şekil - 1) Bu model kullanılarak AAA sertifika politikaları ortak bir yerde tanımlanabilir. Ayrıca politikaların basit ve eş-zamanlı bir şekilde kullanılmasına izin verir. Programlanabilir cihazlar üzerinde servislerin otomatik ve dinamik konfigurasyonu için IETF tarafından COPS ( Genel Açık Politika Servisi - Common Open Policy Service ) tanımlanmıştır.[5,8] COPS politika yöneticisi ile ağ cihazı arasındaki politikaların uyumluluğunu sağlayan bir yapı Şekil-2 de gösterilmiştir. COPS kullanılarak ağ cihazına yeni güvenlik servislerinin eklenmesine ve güncellenmesine olanak sağlar. Ağ cihazlarının AAA politikalarının oluşturulması ve dağıtılmasını sağlayan bir çalışma [5] de yapılmıştır. 3. Açık Anahtar Altyapısındaki Problemler Nitelik ları (Attribute Certificates): X509 daki temel problem açık anahtarların varlıkların niteliklerini belirleyen yapıya dönüştürülmesi problemidir. X509 sertifikaları açık anahtarlar ile varlığın kimlik bilgilerini arasındaki bağlantıyı sağlar ve iletişimin güvenirliğini sağlar. Nitelik sertifikaları, varlıkların erişim haklarını, rolleri ve yeteneklerinin belirleyen ve açık anahtarlar bağlantı kuran yapılardır. Fakat roller ve yetenekler erişimi kontrol ettiğinden ve kimin nereye erişeceğine karar verdiğinden sertifikaların iptali önemli bir problemdir. Bunu sertifika iptal listeleri ile çözümlenmeye çalışılmıştır. Bu yapıda dizin servisinin doğrulanmasından çok genel olarak dijital imzaların doğrulanması vardır. Güvenilir taraf imzayı doğrulamak istediğinde sertifikayı dizinden alır, sonra aynı veya farklı bir dizinden sertifika iptal listesini okur. Daha sonra sertifika iptal listesinden kontrolünü ve son olarak sertifikanın imzasını kontrol eder. [1] Nitelik sertifikalarının X509 üzerinden tanımlanmasıyla mümkün olabildiği [2] de gösterilmiştir. Fakat X509 yapısına bağlı olması diğer problemlerinde beraberinde getirir. Kimlik/İsim Anahtar Şekil 3 da isim ve anahtar ilişkisi

6 İsim/Kimlik Nitelik sı veya ACL Kimlik sı (ID Certificate) İzin/Rol Anahtar Şekil 4 Nitelik ve Kimlik sertifikaları arasındaki yetkilendirme Kimlik sı Problemleri(Idendity Certicates) Global dağıtık bir dizin servisi olmadığından sertifikaların ve onların iptal listelerinin bir dizin servisinden okunması büyük bir problemdir. Geliştiriciler bu problemi Hangi Dizin? kullanılacak sorusuna cevap arayarak ihtiyaç duydukları sertifikaları elde ederler. Örneğin S/MIME imzaları onaylanması için gerekli olan bütün sertifikaları içerir ve SSL sunucusu haberleşmenin korunması için gerekli sertifikalara sahiptir. Güvenilir taraf sertifikaların güncellemesi için e-posta, sorarak veya gerekli sertifikaların kopyalayarak elde eder. ların dağıtımını çözen bu yaklaşımlar sertifikaların iptali için ise pahalı bir transferdir. Diğer bir konuda, bir kişinin ismini kullanarak açık anahtarını elde etmek istediğimizde aynı isimde birden fazla kişi olabileceğinden ve hangisinin istediğimiz kişi olduğu bir problem olarak karşımıza çıkar. Belki kişilerin isimlerinin sonuca kimlik numaraları eklemek gibi geçici çözümler üretilebilir, fakat bunun için güvenilir üçüncü taraflar nasıl bir ortak isim üretileceğini bilemezler. Diğer PGP(Pretty Good Privacy) ve SPKI/SDSI(Simple Public Key Infrastructure/Simple Distributed Security Infrastructure) sertifika modellerinde isimlendirme için kendi yaklaşımları vardır. SDSI global tekil isimleri sadece özel durumlar haricinde kullanılmaz ve sunucular sınırlı bir alanda anlamlı olan isimlere ihtiyaç duyarlar. Daha sonra SPKI ile SDSI isimlerini açık anahtarlarla birlikte kullanarak global tekilliğini sağlar. PGP ise problemi kullanıcılara istedikleri sertifikaları seçmesine izin vererek çözmüştür. Bu genellikle e-posta adresi ve kullanıcı isminden oluşur. Çünkü e-posta adresi ile global tekilliği sağlandığından ve PGP e-posta haberleşmesinde kullanıldığından, bu yaklaşım oldukça iyi çalışmaktadır. Genel olarak baktığımızda belirli bir alan içinde yerel olarak anlamlı kimlikler kullanan PGP ve SPKI aynı mantıksal model üzerine kurulmuştur. PGP çalışma alanını e-posta adresleri olarak görürken, SPKI sınırlı alanlar tanımlayarak belirler. [1]

7 ların İptali (Certificate Revocation) X509 sertifikalarının iptal problemi sertifika iptal listelerinin (CRL-Certificate Revocation List) veri akışının programlanmasındaki problemlerdir. Yani veriler bir defa kullanıldığında tekrar geri almanız mümkün değildir. ların yayınlanması ve iptalini bir yaşam çevrimi olarak düşünürsek, sertifikaların yayınlanması PREPARE komutu ile iptalini ise COMMIT komutu olur. Çeşitli nedenlerle güvenilir olmayan sertifika iptal listeleri ile çalışmak oldukça zordur. Bazı kritik uygulamalar sertifikanın iptal olup olmadığı sormak veya bazen eş zamanlı olarak sorgulamak isteyebilir. Bu sertifika iptal listelerinin çözülemediği problemlerinden birisidir. iptal listelerinin sorunlarına baktığımızda; - Bir kart veya gizli anahtarın ihlaline karşı sertifika iptal listelerinin yeterince sıklıkta yayınlanamıyor. - Listelerin dağıtımı oldukça pahalı yöntem - Listeleri kontrol edilmesi oldukça zaman alıcı bir işlem - Ataklara karşı dirençsizdirler Okuma İmza Kontrol İmzası İptal Kontrol Okuma İptal Listesi(CRL) Şekil 5 X509 sertifikası kullanım modeli Otoriteleri () sertifika iptal listelerini yayınladığında, bununla birlikte yayın tarihi ve sonraki yayın tarihini de gönderir. Pratikte ise kullanıcılar ve uygulamalar bu iptal listelerini nerede bulacaklarını bilmediklerinden kullanmazlar veya listelerin okuması ve kontrol edilmesi uzun sürdüğünden iptal edilir. Ayrıca diğer bazı problemleri de beraberinde getirir. Sunucular zamanında listeleri güncellemek için mümkün olduğunca sık yayınlamaktadır ve bu sunucu üzerindeki yük artışına ve kullanıcılardan gelen iptal listesi istekleri haberleşme bant genişliğinin artmasına sebep olur.

8 Bu sertifika iptal listelerine bir çok çözüm önerilmiştir, bunlar; - Farklı sertifika tipleri için farklı bitiş süreleri alınarak sürekli olarak meşgul edilmesi önlenir. - Yayın süresi geçen listeler için birden fazla listeyi birbiri üzerinde örtüştürerek aynı zamanda gönderilmesi - Listeler iptal bilgisinin acil durumuna göre parçalara ayrılarak yayınlanır, örneğin anahtar ihlalleri. - Fark listeleri yayınlayarak ana listeler çoğaltılarak desteklenir. Diğer bir çözümde gerekli risk analizi yapılarak AAA benzeri iptal listelerini kullanmayarak sağlanabilir. Örneğin ANSI X9.59 (Account Authority Digital Signatures) var olan hesap tabanlı iş altyapısına basit eklentiler ile kullanır. Bu eklentiler anahtarları silerek iptal işlemini yapan sunucularda açık anahtarları saklarlar. SPKI da ise daha farklı bir yaklaşım ile sertifikaların tekrar onaylanmasını sağlayan pozitif bir sorgulama yapar. iptal listeleri ise negatif bir sorgulamayı gösterir. Bu yaklaşımda pozitif sorgulama negatif sorgulamadan daha kolay izlenir. Diğer bir kullanım örneği de SSL Web sunucularında iptal işlemini kullanıcının sunucuya erişimini yasaklayarak sağlamasıdır. Bu yöntem daha çok uygulamaya yönelik çözümdür. Son olarak iptal sertifikalarının kontrolü için OCSP(Online Certificate Status Protocol) öneri olarak sunulmuştur. (Şekil-6) OCSP ile online olarak iptal sertifikalarının kontrolünü en güncel halini sorgulayabilir. OCSP ninde bir dezavantajı sertifikanın doğruluğu için basit bir evet/hayır yerine bir çok sertifikayı kullanmak zorundadır. iptal listeleri sadece negatif sonuç verdiğinden, sertifikanın listede olmaması sertifikanın henüz yayınlanmadığı veya çalındığı anlamına gelmez. Bazı OCSP uygulamalarında iptal listesinde bulamadım rapor cevabı iptal edilmemiş iyi olarak değerlendirilebilir. Yani iptal edilmiş ile aynı anlama gelmediğinden iyi olarak değerlendirilebilir. iptal listelerinde ve OCSP de soru bütünüyle yanlıştır. Şu an sertifika geçerli mi? yerine iptal edildi mi? sorusu yöneltilir. [1] OCSP Sunucusu Okuma onaylama İmza kontrol İmzası Şekil 6 OCSP kullanan sertifika kullanım modeli

9 Zinciri (Certificate Chains) Temel problem hiyerarşinin en altından kök seviyeye kadar bir çok sertifikanın yol boyunca onaylanması gerekir. Çapraz sertifikalar ile hiyerarşideki lar arasındaki kısa yollar oluşturmasına rağmen izlenemez hale getirebilir. Birden fazla sertifika yolu verildiğinde en alt hiyerarşi seviyesinden onaylanmaya başlandığında, sertifika yolları döngüler içerebilir. Çapraz sertifikalar ile bu daha da karmaşık hale gelebilir. Alternatif olarak iki veya daha fazla arasına Köprü- ile tek bir kök sağlanarak bu tip sertifika zinciri problemlerinden kaçınılabilir. Şekil 7 Sertfika hiyaraşisi ve çapraz sertifikalarının meydan getirdiği karışıklık zincirleri ile çalışırken Hangi dizin? diye sorulduğunda bu yaklaşım sadece tek bir dizini değil farklı ve SİL ler için bir çok dizin içerecektir. Sunucu bütün olası yollar üzerindeki sertifikaların kullanacağından çapraz sertifikalar kompleks bir problem haline gelir. Bunun için bir çözüm sertifika yollarını onaylayan son kullanıcıdan zincir-yolu oluşturma yükünü alan bir sunucu kullanmaktır. Yol doğrulayıcı sunucuları ile yolların doğrulanması işleminden sadece doğrulama işlemine kaymış olur. [1] Standart olmayan X509 ve Eklentileri: ların standardizasyonunda I/IEC/ITU-T açık anahtar sertifika ve iptal listesi formatları ile ilgilenirken ağ üzerinden AAA kullanılmasıyla ilgili standartları ise IETF tarafından yürütmektedir. Standartların ilk olarak geliştirildiğinden beri ihtiyaçları karşılayabilmek için bir çok versiyon çıkmıştır. Son olarak geliştirilen X509v3 sertifika standardında üreticilerin ihtiyaçlarını karşılaması için seçimlik eklentiler yapılmıştır. Üreticiler kendi uygulamalarına özgü eklentiler kullanmakta ve sertifika standardından uzaklaşarak uygulamalar arası entegrasyonu güçleştirmektedir. Bunun çözümü için üreticilerin bir standart alanda buluşmaları gerekir. ların Onaylanması Otoritelerinin birbirinde çok uzakta bulunan kullanıcılar için yayınladığı sertifikaların güvenilirliği bir problemdir. Örneğin Web Browser üzerinde bulanan sertifikalara hangi otoritenin izin verdiği önemlidir. Ayrıca üzerinde bulunmayan bir otoritenin sertifikası geldiğinde, kullanıcıdan sertifikanın onaylamasını istemesi durumunda ne yapılacak?

10 Bazı AAA sistemlerinde sertifikaların üretim hakkı diğer şirketlere verilebilmektedir. Bu durumda bir şirket yetkili bir otoriteyi dikkate almaz ise, aynı şekilde bir Kayıt Otoritesinden sertifika yayın haklarını da alabilir. Şirket kullanıcılarının düzgün bir şekilde onaylanmayı aksatarak sertifikaları yayınlaması, satın aldığı haklar ve anlaşmaların doğruluğu risk altına sokar. [3] ve KO nun birlikte kullanılması Otoritesi ve Kayıt Otoritesi birlikte kullanıldığı sistem sadece Otoritesini kullanıldığı sistemden daha az güvenlidir. Çünkü bazı +KO sistemlerinde nun sertifikanın bütünüyle ilgili zorlaması gereken yetkileri içermeyebilir. Bu da bir zinciri güvenliği en zayıf halkasına bağlı olacağından +KO diğer sadece veya KO içeren sistemlerden zayıftır. [4] 4. Sonuç AAA, son yıllarda bilgisayar güvenliği alanında en çok tartışmalı konulardan biri olmuştur. Fakat hala sadece teorik olarak değerini korumaktadır. Bazılarına göre de önemli bir teknolojik gelişme sağlanamamıştır. AAA daki sorunlara kısaca baktığımızda [6]; Açık standartların uygulanmaması, belli başlı büyük üreticiler arasındaki uyumsuzluk ların iptali, büyük sayıda istemci isteklerinin karşılanması teorik olarak hala problem Genişletilebilirlik, güvenlik ihtiyaçlarını karşılayacak erişim denetim ve yetkilendirme gibi konularda nitelik sertifikalarının kullanılmasının sağlanması. Sunucu ve istemci uygulamalarının geliştiriciler tarafından var olan AAA sistemine entegre edilmesinin zorluğu Gereğinden fazla kompleks; daha öncede görüldüğü gibi geliştirilen OSI ve X400 standart olarak sunulduğu ve daha sonra çok kompleks olması sebebiyle OSI ve X400 yerine kullanışlı olan TCP/IP ve SMTP geliştirildiği görülür. Maliyet faktörü İş ortamı ihtiyaçlarının karşılanması; iş ortamında ihtiyaç duyulan kompleks güvenilirlik ilişkileri veya S(Single Sign-On) sistemlerinin karşılanması gibi sorunlar bulunmaktadır. Genel olarak kesin çözüm sağlayan AAA yapısı sağlanmamasının sebepleri arasında;

11 AAA teknolojiyi sunan kişiler tarafından geliştirilmiş ve iş dünyası AAA ortamına uydurulmaya çalışılmıştır. Şu anki AAA, Kiminle konuşuyorum?, Konuştuğum kişi doğru kişi mi? Gibi gizlikle ilgili konular üzerine yoğunlaşmıştır. Fakat iş akışı sorumluluklar ile ilgilenir. AAA nın iş süreçleri yerine teknik konular olan uygulamalar ile ilgilenmiştir.

12 Kaynakça [1] Gutmann P, PKI: It s Not Dead, Just Resting, IEEE Computer Society, page 41-49, 2002 [2] Hwang J.-J., Wu K.-C., Liu D.-R., Access control with role attribute certificates, Computer Standards & Interfaces 22, page 43 53, 2000 [3] Hunt R., Technological infrastructure for PKI and digital certification, Computer Communications 24 (2001), page , 2001 [4] Ellison C., Schneier B, Ten Risks of PKI: What You re not Being Told about Public Key Infrastructure, Computer Security Journal, Volume XVI, Number 1, 2000 [5] F. Gómez,A., Mart ýnez G, Cánovas Ó, New security services based on PKI, Future Generation Computer Systems 19 (2003), page , 2003 [6] IEEE Enterprise Security Workshop and Panel Discussion on PKI, 1999, [7] Common Information Model (CIM) Standards, DMTF. [8] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, The COPS (Common Open Policy Service) Protocol, IETF, January 2000, Request for Comments (RFC) 2748.