Ödeme sistemleri ve güvenliği [4] — Key tipleri ve yapıları

Önsöz: Bu yazı; serinin -şimdilik- son yazısıdır. Ödeme sistemleri tip HSM için key yaklaşımlarını irdeler ve bilgi verir.

Serinin diğer yazıları:
Ödeme sistemleri ve güvenliği [1] — HSM nedir
Ödeme sistemleri ve güvenliği [2] — Kriptoloji
Ödeme sistemleri ve güvenliği [3] — Yazılımlarımızda HSM ‘i kullanma
Ödeme sistemleri ve güvenliği [4] — Key tipleri ve yapıları

Merhaba sevgili gönül dostları. Gün geçmiyor ki; -fırsatım olsun da- yine çok faydalı, toplumları ışığı ile aydınlatan, teknik/sosyal yazılar yazmış olmayayım. Zaten genellikle ofise girmemle birlikte etrafın aydınlandığını söylerler. Tamam, bu ofise girer girmez ışıkları yakma alışkanlığım ile alakalı olabilir ama diğer anlamı için de uğraşıyorum yani. Çok şaapmayın.

Herneyse bugün -sanırım- ödeme sistemleri serimizin son yazısı ile karşınızdayım. HSM ‘ler, algoritmalar, donanım yapıları hatta pkcs11 den bile bahsettik. Son olarak, aslında daha çok ödeme sistemleri tipi HSM ‘i ilgilendiren key tipleri ve yapılarından bahsetmediğimizi farkettim.

Önce tipler diyelim. Kriptolojide “Her anahtar yalnızca bir kilidi açar” diye bit motto var. Öncelikle ihtiyaçlarımıza göre bir sürü anahtar üretelim ve her anahtar sadece bir amaç için kullanılsın denilmiş. (Paralel evrende “Single Responsibility” e denk düşer. Gökhan abiye selam olsun) Burada ana amaç aslında güvenlik. Anahtarın ifşa olması yada kaybolması durumunda etkilencek buisness ‘ı sınırlamak.

Sonra bu anahtarları da kullanım amacına göre isimlendirmişiz. Hatırlarsınız serinin daha önceki bir yazısında AES yada RSA gibi tiplerden bahsetmiştik. Aslında buradaki durum o tiplerden biraz farklı. AES yada RSA key şeklinde bahsettiğimiz şey algoritma bazlı bir isimlendirme idi. AES key derken AES algoritmasına vereceğimiz anahtardan bahsediyorduk. Şimdilik bu yazıda bahsedeceğimiz tüm keylerin mesela AES tipinde keyler olduğunu düşünebilirsiniz.

Evet kullanım amacına göre isimlendirmişiz demiştik. Mesela HSM içersinde bir ana anahtar oluşturmuşuz ve tüm alt anahtarlar, işlemler vs hep bu anahtara bağlı olarak işlenmiş. Bunun adı da Local Master Key (nam-ı değer LMK) olmuş. Ödeme sistemleri tipi için her HSM ‘in kendine özel bir LMK ‘sı var. Ve kesinlikle dışarı çıkartılamaz kabul ediliyor.

Aslında çok detaya girmek istemiyorum ama bunu söylemeden geçemeyeceğim. LMK ‘lar dışarı çıkarılamaz ama içeri sokulabilir. Bir LMK yı elimizde bulunan componentler ile HSM ‘e biz init edebiliriz. (Daha önceki yazımızda bu componentlerin farklı kasalarda fiziksel olarak saklandığını söylemiştik) Böylelikle aynı LMK ya sahip birden fazla HSM ‘imiz olabilir. (Ayrıca LMK smart kart içerisinde tutulur ve farklı HSM ‘lere kopyalanabilir.)

Ama her zaman LMK yeterli gelmez. Bazen HSM ‘e özel değil bir gruba yada alana özel key ‘e de ihtiyaç duyarız. Mesela ödeme sistemleri tip HSM ‘imiz içindeki bir AES keyi genel amaçlı tip bir HSM ‘e taşımak isteyebiliriz. Herhangi bir keyi HSM dışına clear olarak çıkarmak mümkün olmadığı için bu taşıma işleminde ortak bir anahtar kullanırız. Önce kaynak HSM den ilgili key grup keyi altında şifrelenerek (wrap key) çıkarılır. Sonra yine bu grup keyine sahip olan hedef HSM ‘e yüklenir (unwrap). Taşıma esnasında şifreleme ve şifre çözme işlemleri hep ortak anahtar ile yapılır. Bu keyin ismi de Zone Master Key yani kısaca ZMK.

Örnekleri çoğaltmak mümkün. İşte bu gibi durumlar dolayısı ile bir sürü genel kabul görmüş key tipi var. PEK, KEK, TPK, TMK ilk aklıma gelenler. Hatta gerekirse siz kendi işiniz için kendi tipinizi de isimlendirebilirsiniz.

Bunun yanında bazı key tipleri için bazı standartlar/kısıtlamalar da koyabilirsiniz. Mesela ÖGK tipi (yani Ömer General Key) sadece 256 bit AES olabilir diyebilirsiniz. Yada daha gerçek bir örnek vermek gerekirse variant bir LMK single DES olamaz dersiniz.

Eyvah Varyant dedim. Yazı zaten yeteri kadar karmaşık değil mi? Nerden çıktı bu yeni zımbırtı! Bu aslında başlığımızdaki “yapılar” kelimesine denk gelen kısım. Keyleri algoritmaya ve kullanım amacına göre isimlendirdiğimizi konuştuk. Bir de bunlara ek olarak ödeme sitemleri tip HSM için Keyblock ve Variant isminde iki farklı yapı var.

Temelde bunlara birbirinin alternatifi olarak bakabiliriz. Önceleri sadece Variant (kısaca VAR) varmış sonradan daha güvenli ve hızlı olan Keyblock (kısaca KB) çıkmış. Zaten aşama aşama tüm bankalar ve ödeme kuruluşları Keyblock ‘a keylerini göç ettiriyor/ettirecek. Amerikada bu tür standarları belirleyen NIST isminde bir kuruluş var. Bu tür regülasyonları ve güvenlik kabullenimlerini bu kuruluş yayınlıyor.

KB ve VAR genel olarak birbirinin yerine kullanılabilse de 100% birbirinin alternatifi değiller aslında. Mesela VAR için max 2048 bit AES ‘i koruyabilir diye bir bilgi var. Yada yanlış hatırlamıyor isem HMAC keyler AES LMK ile korunabilir AES LMK da yalnızca KB de var.

Bu gibi istisna durumları saymaz isek -özellikle geçiş sürecinde- KB ve VAR tipteki keyleri birbirine dönüştürüp birbiri yerine kullanabiliyoruz. Daha önce yine ödeme sistemleri tipi HSM için TCP mesajlar ile direk iletişim kurulabilir demiştik. Bu mesajlar içerisinde çalıştırmak istediğimiz komut ve parametreleri iletiyorduk. Dökümana bakarsak her komut içinde kullanılabilecek key tipleri ve yöntemleri mevcut. Mesela komut içerisinde bir key parametre olarak isteniyor ise döküman KB için şu şekilde VAR için şu şekilde gönderin diye tarifte bulunuyor.

Herşeyden önce KB için de VAR için de bir LMK anahtarımız var. Tek fark şu; VAR için yalnızca 2DES ve 3DES tipinde oluşturulabiliyorken KB için AES ve 3DES tipinde oluşturulabiliyor.

KB ve VAR arasındaki en bariz fark temeldeki çalışma mekanizmalarıdır. VAR bir LMK ürettiğimizde HSM bizim LMK ile bağlı halde 20 adet daha (pair) alt key üretir. Bu keyleri de komut çalıştırıken yeri geldikçe kullanır. Mesela VAR bir LMK altında ZMK ile bir işlem yapmak istersem HSM hemen gider bu işlem için “04–05” numaralı pair key i kullanır.

[Bu konu sanırım key-usage. Bunu Salih ‘e sorup bir paragraf daha ekleyeceğim]

Ama tabi biz dışarıdan VAR keyleri kullanırken bu detayda bilmek zorunda değiliz. Biz sadece istediğimiz komut ve parametrelerini göndeririz; HSM kendisi işlem için gerekli pair key ‘i içeride bularak bizim için sonuç üretir.

KB için pair keyler yoktur

Bir de şemalar var. Aslında bu keylerin daha anlaşılabilir olmasını sağlayan bir etiket/yaklaşım. Key dediğimiz şey uzun bir string. HSM; daha anlaşılabilir olması için bu keyin başına bir karakter daha ekliyor ve biz ona bakarak key ve LMK sı hakkıdna bilgi sahibi olabiliyoruz.

Yine VAR dan başlayalım. 2 tip LMK olabilir demiştik; 2DES ve 3DES. 2DES keyler “U” ile başlar ve toplamda 33 karakterdir. Aynı şekilde 3DES keyler de “T” ile başlar ve toplamda 49 karakterdir. Yani biz bir keyin U ile başladığını görürsek direk VAR LMK altında üretilmiş 2DES bir key olduğunu ve toplam uzunluğunun 33 karakter olduğunu yorumlayabiliriz. U ve T gibi başlangıç karakterlerine keyin şeması deriz.

VAR tipi için yalnızca bir istisna var Single DES tipinde bir LMK üretilemese de bu LMK altında Single DES keyler üretmek mümkün. Bunlar da şemasız keyler olarak geçer ve toplamda 16 karakterdir. (Şema olmadığı için +1 koymadık)

KB keyler için ise yalnızca S şeması vardır. Yani KB keyler S ile başlamak zorundadır yada key S ile başlıyor ise KB ‘dur diyebiliriz. Bu keyin uzunluğu sabit değildir. KB daha modern olduğu için keyi parse ederek bazı bilgileri elde edebiliriz;

• İlk karakter “S” keyin şeması
• İkinci karakter LMK tipini (0 ise 3des 1 ise aes)
• Devam eden 4 karakter keyin uzunluğunu (mesela 0096 ise key toplam 97 karakter şema dahil)
• Devam eden 2 karakter key usage yani keyin tipi (52 ZMK mesela)
• Devam eden 1 karakter algoritma (T: tribledes, A: aes, R: rsa, H: hmac)
• Devam eden 1 karakter mode of use yani kullanım amacı (enc, dec, sign vs. N herşeyi yapar)
• Devam eden 2 karakter keyin versiyonu
• Devam eden 1 karakter key export edilebilme durumu
• …….

T, U ve S dışında 2 şemadan daha bahsetmek istiyorum. X ve R şeması. Bunlar taşıma şemalarıdır. Keylerimizi bazen çeşitli amaçlar için HSM dışına çıkarmak isteriz. Keyi clear olarak dışarı çıkarmak mümkün olmasa da HSM bize şifreli olarak istediğimiz keyleri verebilir. İşte biz keylerimizi dışarı çıkarırken X yada R da dışarı çıkarmak istiyorum diyebiliriz. Yani bu iki şema hem VAR hem KB keyleri dışar çıkarmak için kullanılabilir. Bu seçim güvenlik içindir. İki şema tipi için de yine NIST izin vermiş ve birbirinden farkını tanımlamıştır. (Ayrıca istersek keyi mevcut şeması ile de taşıyabiliriz. Mesela U şemasında keyi HSM dışına U şeması ile çıkarmak mümkündür ama keyi U ile dışarı çıkarmak R kadar güvenli değildir. Ben NIST ‘in yalancısıyım)

Bu yaklaşım bizim VAR ve KB keylerini birbirine dönüştürmemizi kolaylaştırır. Mesela VAR bir keyi X şeması ile HSM dışına çıkarırız sonra bu X şemalı keyi import ederken KB olarak import etmek istiyorum diyerek VAR dan KB a dönüşümü sağlamış oluruz.

Son olarak HSM ‘e console üzerinden bağlanıp bazı ayarlamalar yapabiliyor ve key yaratmak gibi işlemleri gerçekleştirebiliyoruz. Bu işlemler komutlar ve menüler üzerinden yapılıyor. Switch yönetmeye benzer bir yapısı var. Bu biraz daha destek tarafını ilgilendirdiği için çok detaya girmiyorum.

Evet. Böylelikle bir yazımızın daha sonuna geldik. Yazmaya başlarken bu kadar beyin yakıcı bir yazı olmasını beklemiyordum. Sanırım serinin en sıkıcı yazısı bu oldu. Bu durumda yeni bir yazı daha yazmalı ve bu işin teoride kalmasını önlemeliyim. Sağlıcakla.

Serinin diğer yazıları:
Ödeme sistemleri ve güvenliği [1] — HSM nedir
Ödeme sistemleri ve güvenliği [2] — Kriptoloji
Ödeme sistemleri ve güvenliği [3] — Yazılımlarımızda HSM ‘i kullanma
Ödeme sistemleri ve güvenliği [4] — Key tipleri ve yapıları