Son yıllarda hayatımıza girmiş bir kavram olan Key Block konusunu Cyberwise Siber Güvenlik Firmasının Veri Güvenliği Takım Lideri Onay Küçükesin Siber Bülten için ayrıntılı olarak anlattı:
Key Block Diğer adı ile ANSI TR-31, 2014 yılında yayımlanan bültenle 2018 yılı itibariyle kullanıma geçmesi planlanmış bir şifreleme formatı. Ancak altyapı hazırlıklarının uzun sürmesi ve firmalar arası uyumun kolay sağlanabilmesi için 2019 yılından itibaren 3 faza ayrılmış süreçle kullanıma geçilmesine karar verildi.
Bu sürecin Haziran 2021’de başlayacak ikinci fazı Zone’lar arası keyblock formatı uygulaması da Kovid-19 nedeni ile Ocak 2023 tarihine ertelendi.
Şu anda kullanılan format olan ANSI X9.17, basit olarak anahtarın, belirli algoritmalarla şifrelenmiş halinin saklanması temeline dayanıyor.
3DES bir anahtarı örnek alırsak, 24 Byte olan bu anahtarın X9.17 formatında şifrelenmiş hali de yine 24 Byte bir veri olarak görünüyor. Aşağıdaki tabloda görüldüğü gibi bu formatta anahtarın şifreli hali, anahtarın kullanım amacıyla da ilgili tipi gibi özelliklerini belirten bir alan bulunmuyor.
Anahtarın ne amaçla kullanılacağı, anahtarı oluştururken girilen bilgilere bağlı oluyor ve bu bilgiler kaybedilirse süreçle ilgili sorunlara neden olabiliyor. Ek olarak belirli bir kontrol mekanizması olmadığı için, anahtar zafiyet oluşturabilecek farklı amaçlarla kullanılabiliyor ve güvenlik riski yaratıyor.
Keyblock formatı işte tüm bu sorunlara çözüm olacak yeni özellikler getiriyor. Bu özellikleri inceleyebilmek için örnek bir Anahtar üzerinden yola çıkarabiliriz.
X9.17 formatındaki anahtar ile aynı boyutta yani 24 Byte olan bu anahtarın keyblock formatındaki gösterilişi çok daha uzun. Bu şekilde uzun olmasının sebebi ise keyblock formatına eklenen özellikleri anahtar ile birlikte taşıyan ek bölümlerinin olması. Anahtarımızı bu bölümlere ayırarak ilerlersek, karşımıza aşağıdaki örnekte görüldüğü gibi 5 ana bölüm çıkıyor.
- Keyblock’un başındaki S harfi; anahtarın Keyblock formatında olduğu gösterir ve sabittir.
- En önemli ana bölüm olan Keyblock Header; anahtar ile birlikte taşınacak özelliklerini barındırır. Birazdan bu bölüm ile ilgili detaylı bir inceleme yapacağız.
- Optional Header; anahtar ile birlikte taşınmasını istediğimiz, önceden belirlenmiş ya da bizim seçeceğimiz bilgiler barındırır.
- Key Status alanı; anahtarın hangi durumda olduğunu gösterir. Bunlar Live, Pending, Revoked, Expired ve Test olabilir ve uygulama tarafından mevcut anahtar üzerinde değiştirilebilirler. Bu alandaki bilgilere göre HSM anahtarlarının kullanılıp kullanmaması gerektiğine karar verir. Start Date ve End Date; anahtarın kullanılabilir olacağı tarih ve saat aralığını belirlememizi sağlar. Text alanı ise okunabilir karakterler ile yazacağımız bilgilerin anahtar ile birlikte taşınması için kullanılabilir. Örneğimizde anahtarın hangi amaçla kullanıldığını belirtmek için bir değer girildiği görülebilir. Bir sonraki alan, anahtarın gerçek uzunluğu ve anahtarın şifrelenmiş halinden oluşur. Bu değer tüm keyblock’a özgü olacağından ayrıca alınıp kullanılamaz.
- Son olarak Authentication Block Bu bölüm anahtar üzerinde yapılacak herhangi bir değişiklikte farklılık gösterecek hash alanıdır ve anahtarın yaratıldığı ya da import edildiği LMK değeriyle birlikte hesaplanır. Bu nedenle hem anahtarda değişiklik yapıldığında kullanılır hem de farklı bir LMK altında kullanılmasını engelleyen bir mekanizma sağlar. Şimdi tüm bu alanların içerisindeki özellikleri tek tek inceleyelim:
Kolay Erişim
KEYBLOCK HEADER NEDİR?
- Header içerisindeki ilk karakter 0 ya da 1 olabilir ve Anahtarın 0 için DES, 1 için AES olduğunu belirtir.
- Sıradaki 4 karakterlik alan, başındaki S karakteri dışındaki tüm Keyblock’un uzunluğunu byte cinsinden gösterir. Optional header uzunluğu değişiklik gösterebileceğinden bunu anahtarın uzunluğu ile karıştırmamak gerekir.
- Üçüncü alan, 2 karakterden oluşur ve Key Usage alanıdır. Bu alanda girilen değer anahtar oluşturulurken belirlenir ve daha sonra değiştirilemez. Bu alandaki değer, Anahtarın kullanım amacını belirtir. Örneğin ZMK oluştururken bu alan K0 olarak, ZPK oluştururken ise P0 olarak verilmelidir.
- Dördüncü alan tek kararter içerir ve anahtarın kullanılabileceği algoritmayı belirtir. Bunlar şu an için AES, DES, RSA ve HMAC’ken gelecekte yeni algoritmalar eklenebilir.
- Sıradaki alan yine tek karakter içerir ve anahtarın kullanım amacına göre değişiklik gösterir. Anahtar bir encryption key ya da wrapper key ise işlevi Encryption ya da decryption ile sınırlandırılabilir ya da ikisine de izin verilebilir. Eğer anahtar bir RSA anahtar ise bu durumda işlevi Sign ya da verify olarak sınırlandırılabilir ya da her ikisine de izin verilebilir. Bu alanın doğru kullanılması güvenlik konusunda ciddi katkılar sağlamaktadır. Bu konuyu detaylı bir şekilde inceleyeceğiz.
- Sıradaki alan Versiyon numarasını içerir. Bu alan anahtar oluşturulurken verilir ve anahtarların takibi konusunda uygulamaya ve anahtar sahiplerine kolaylık sağlar.
- Exportability alanı, anahtarın sadece güvenli olan keyblock formatında mı yoksa mümkün olan tüm formatlarda mı export edilebileceğini ya da hiç export edilemeyeceğini belirtir. Özellikle import edildikten sonra yeniden export edilme ihtiyacı olmayan anahtarlar için export işlemine izin verilmeyecek şekilde import işlemi yapılmalıdır.
OPTIONAL HEADER NEDİR?
Bu bölüm block sayısını belirtir. Eğer optional header block eklenmeyeceksse “00” olarak girilmelidir. Girilecekse bu durumda kaç adet farklı optional header block ekleneceği bu alanda belirtilmelidir. Son alan ise anahtarın yaratıldığı LMK ID’sini içerir. Bu alan anahtar yaratılırken girilmez, HSM tarafından otomatik olarak eklenir. İç kullanım amaçlı anahtarların authentication block ile doğrulanması için gereklidir. Anahtarın export edilmesi durumunda bu alan HSM tarafından FF olarak değiştirilir ve böylece her LMK ile import edilebilir olur.
Mevcut anahtarlarımızı Keyblock formatına geçirirken ya da keyblock formatında yeni bir anahtar oluştururken, tüm bu alanların doğru bir şekilde belirlenmesi gerekir. Tecrübelerimizde, anahtarların bu özelliklerinin netleştirilmesi ek çalışma gerektirdiğinden, en hızlı ve kolay yöntem olan mümkün olan en serbest özelliklerin kullanıldığını gördük. Bu şekilde yaratılan anahtarlar görevini yerine getirse de, keyblock geçişi ile sağlanması beklenen güvenlik seviyesini sağlayamadığından güvenlik riskleri oluşturabilir ve gelecekte yeniden değiştirilmesi gerekeceğinden ek operasyon gücü harcanmasına neden olacaktır.
Bu durumu basit bir örnekle inceleyelim:
- A firması, ödeme bilgisi oluşturan ve bu bilgiyi şifreleyerek B firmasına ödemenin işlenmesi için gönderiyor olsun. İki firmanın data encryption Key’i en serbest özellikler ile yaratması durumunda anahtarımız data encryption ve decryption yapabilecek ve export edilebilecektir. Anahtar bu şekilde görevini yerine getirecek ve A firmasında encrypt edilen veri, B firması tarafından decrypt edilerek işlenebilecektir. Bu noktada güvenlik açısından A firmasının gözünden bakarsak, A firması kendi anahtarının güvenliğini sağlayacak önlemleri almış ve ödeme verisinin sadece yetkili uygulamaları tarafından oluşturulabileceğini garantilemiştir. Ancak B firmasındaki güvenlik standartları konusunda söz sahibi değildir.
- B firmasına erişimi olan Rogue bir uygulamanın olduğunu düşünelim. Bu uygulamanın A firmasına ait anahtarı HSM’den export etmesi ya da anahtarın tutulduğu Database’den edinmesi durumunda, sahte bir ödeme verisi oluşturup, bu veriyi A firmasına ait anahtar ile encrypt ederek işleme alınması için sisteme gönderebilir. Bu senaryoda A firmasının bu süreçte hiçbir kontrolü olmaz.
- Yapımızı güvenli hale getirmek için, aynı anahtarın A firmasında sadece encryption yapabilmesi ve B firmasında sadece Decrytion yapabilmesi aynı zamanda export edilememesi sağlanabilir.
Bu durumda Rogue Uygulamamız B firmasına ulaştığında, anahtara ulaşmak için HSM üzerinden export etmeyi deneyebilir, ancak anahtar exportable olmadığından bunu başaramaz.
Anahtarı Database’den aldığını düşünelim. Bu durumda da anahtarın encryption yapma özelliği olmadığı için sahte ödeme verisini encrypt edemez ve dolayısı ile sisteme sahte veri gönderemez.
Böylece A firması kendi sisteminde Anahtarlarının güvenliğini sağladığı sürece, kendisi adına sahte ödeme verisi gönderilemeyeceğinden emin olur.
X9.17 FORMATINDAN KEYBLOCK FORMATINA GEÇİŞTE BİZİ NELER BEKLİYOR?
- Anahtarların ağırlıklı olarak tutulduğu database tabloları üzerinde, anahtar uzunluğundaki değişime uygun değişiklikler yapılması gerekecek. Sabit uzunluktaki sütunların serbest uzunluğa dönüştürülmesi yeterli olacaktır.
- Geçişe hazırlanırken HSM ve anahtarlar ile ilgili yapılması gereken işlemler olacaktır. Öncelikle HSM üzerinde keyblock formatında bir Master Key oluşturulması gerekecektir. Bu anahtarın AES olması gelecekte yeniden değişiklik gerektirmemesi için önemlidir.
- AES LMK oluşturulacak ise HSM’in AES algoritmasını destekleyen lisanslara sahip olduğundan emin olmak gerekir. Hali hazırda kullanılan anahtarların listesinin oluşturulması, hangi amaçla kullanıldıklarının ve keyblock formatında hangi özellikleri almaları gerektiğinin belirlenmesi gerekecektir. Mevcut key tipi bilinmeyen anahtarların Keyblock formatına dönüştürülmesi mümkün olmakla birlikte ek efor gerektirecektir. Çalışan sistemin yapısına bağlı olarak, anahtarlar geçiş öncesi ya da geçiş sırasında Keyblock formatına dönüştürülebilirler. Bu geçişin kesintisiz yapılabilmesi mümkündür, ancak ek uygulama geliştirme efor gerektirir. Keyblock formatına geçişte yazılım üzerinde değişiklikler gerekecektir.
- HSM’e gönderilen tüm komutlar incelenmeli, keyblock formatındaki anahtarları ve verileri kabul edecek şekilde değiştirilmelidir. Fazlı geçiş nedeni ile yazılım üzerinde mevcutta olmayan HSM fonksiyonlarına ihtiyaç olacaktır. Fazlı geçiş sırasında anahtar paylaşımı X9.17 formatında yapılırken, bu anahtarın kullanımının Keyblock ile olması gerekebilir. Bu durumda iki formatı da destekleyecek bir HSM ile iki format arasında geçişi sağlayacak ek fonksiyonlar oluşturulmalıdır. Oluşturulacak bu ek fonksiyonların hangi durumlarda kullanılacağının belirlenmesini sağlayacak kontroller oluşturulmalıdır. Örneğin Keyblock formatında anahtar paylaşımını destekleyen bir firma ile bu şekilde paylaşım yapabilecek, desteklemeyen bir firma ile X9.17 formatında anahtar paylaşımı yapabilecek bir kontrol mekanizması gerekecektir.
- Henüz mecburi olmayan ancak gelecekte 3DES anahtarların yerini alacağını düşündüğümüz AES anahtarları kullanabilmek için keyblock geçişinde AES master key yaratılması tavsiye edilmektedir.Keyblock formatındaki hiçbir anahtar X9.17 formatına dönüştürülemez.DES bir anahtar, X9.17 formatında paylaşıldığında, alıcı firma tarafından import sırasında Keyblock formatına dönüştürülebilir. Ancak aynı durum AES anahtarlar için geçerli değildir.
- AES anahtarlar sadece Keyblock formatında export edilip bu formatta iletildiğinde import edilebilir. Keyblock formatını desteklemeyen bir HSM ile export edilmiş bir AES anahtar, keyblock formatını destekleyen bir HSM’e import edilemeyeceğinden, AES anahtar ihtiyacı olan sistemlerde anahtar paylaşımı konusunda tüm partilerin ortak bir format ya da HSM tipi belirleyerek ilerlemesi gerekecektir. Keyblock geçişi sancılı olacağı kadar anahtar ve veri güvenliği açısından faydalı bir değişim olacaktır. Her ne kadar faz iki ertelenmiş olsa da geçiş hazırlıklarına mümkün olduğu kadar erken başlanılması gerektiğini vurgulamak isteriz.
