Ödeme sistemleri ve güvenliği [1] — HSM nedir
Önsöz: Bu yazı; serinin birinci yazısıdır. HSM nedir ve tipleri nelerdir sorusuna gerçek hayat örnekleri ile cevap vermeye çalışır.
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ı
Merhabalar değerli okuyucu. Yine güzel bir cumartesi sabahına uyanıp; kahvaltımı yapıp; duşumu alıp kendi kendime dedim ki: “Ya Ömer, tam 1 senedir ödeme sistemleri güvenliği sektöründe çalışıyorsun. Bir seri yazı yazsan da bu millet ilminden irfanından biraz istifade etse, aydınlansa! Sen ne kadar düşüncesiz, ne kadar bencil bir insan oldun…” *swh
Daha doğrusu bir arkadaşımla buluşma planım var ama saçlarım ıslak ve hava da epeyce soğuk olduğu için 1–2 saat bişeyler karalayayım, hasta olmayayım dedim; oturdum bilgisayarın başına.
Az önce de değindiğim üzere bu alanda 1 seneyi anlımızın akıyla tamamladık hamdossun. Bu vesile; sektöre bir nebze dışardan bakabilen birisi olarak kriptoloji nedir, HSM nedir, ödeme sistemlerinin güvenliği nasıl sağlanır gibi konuları olabildiğince basitleştirerek anlatmaya çalışacağım. Biraz daha popülist ifade etmek gerekirse; Sen sevgili okuyucu! Kartını pos makinesine okuttuğunda arka planda neler oluyor yada online bir alışverişte ödemen nasıl doğrulanıyor öğrenmek istemez misin?
Herneyse sevgili dostlar, ilk konumuz HSM. Yani Hardware Security Module. Yani Donanımsal Güvenlik Modülü. Sonra sırası ile anahtarlar, algoritmalar, standartlar ve yöntemler gibi detaylara gireceğim.
Tüm ödeme sistemlerinin göbeğinde HSM var. Aslında sadece ödeme diye kısıtlamak doğru olmaz. Daha genel olarak kriptoloji ‘nin merkezinde diyelim. Örneğin savaş esnasında önemli mesajların güvenli bir biçimde iletilmesini bile sağlayan şey bu.
Adından da anlaşılacağı üzere bu bir cihaz. Fiziksel bir donanım yani. Amacı şifreleme ve şifre çözme gibi kriptoloji işlemlerinde kullandığımız anahtarlarımızı ve objelerimizi (güvenli bir biçimde) saklamak ve bu işlemleri cihazın içerisinde yapmak. Anahtarınızı çeşitli yöntemler kullanarak bu cihazın içine atıyor yada direkt olarak içinde oluşturuyorsunuz sonra o anahtar -bir tehdit algılanmadığı müddetçe- sonsuza kadar cihazın içinde kalıyor. Örneğin bir veri şifreleme mi yapmak istiyorsunuz veriyi cihaza gönderiyorsunuz o sizin yerinize anahtarınızı kullanarak sizin istediğiniz algoritma ile şifreleyip size şifrelenmiş datayı dönüyor.
Bu saklama işini de -olabildiğince- en profesyonel biçinde yapıyor diyebiliriz. Öyle HSM ‘ler var ki; kabini biraz sallasanız “Biri beni kaçırıyor sanırım” diyip tüm anahtarlarınızı silebiliyor. Kurcalama sensörü, ışık sensörü, hareket sensörü… Bunlar gibi onlarca fiziksel koruma mevcut. Bunun yanında; tüketilen enerjiden, üretilen sesden / radyasyondan vs içerideki işlemin tespit edilememesi için bir sürü yan kanal koruması da var.
Şayet cihaz anormal bir durum sezerse -bir prosedür dahilinde- içerideki keylerin, objelerin tamamını siliyor. Buna temper mekanizması deniyor.
- Gerçekten mi?
- Valla billa!
[Eğer bu yazı yeteri kadar ilgi görürse bu alana temper mekanizmasının çalışma prensibi hakkında detaylar gelecek. (spoiler: ios keychain)]
Eee peki bir bankayı düşünelim. Elinde bir key var ve bununla bir sürü kredi kartı üretmiş müşterilerine dağıtmış. Oldu da bu key, HSM temper ‘e girince silindi. O zaman ne olacak yani banka müşterileri arayıp “Kusura bakmayın bizim key silindi size yeni kart göndereceğim eskisini kullanamazsınız” mı diyecek? Tabii ki hayır. Bu tür durumlardan korunmak için iki yöntem oluşmuş. Bunlardan bir tanesi replika HSM. Mevcut HSM ‘lerimizdeki keyleri ikinci bir HSM ‘de replika olarak tutuyoruz. Böylelikle bir HSM ‘in başına birşey gelirse ikinci HSM ‘de key korunmaya devam ediyor.
Bu konuyu biraz açacağım. Aslında yukarıda key HSM ‘den dışarıya çıkarılamaz demiştik. Burada bir nüans var. Dışarı kelimesinden kasıt güvensiz ortama şifresiz bir biçimde çıkarılamaz. Bu ne demek? Mesela içeride bir keyiniz var bunu oluşturuken eğer tersini tanımlamadı iseniz şifreli bir biçimde dışarı çıkabilirsiniz. Bu şifre matematiksel olarak çözülemez kabul edildiği için dışarıdaki şifreli data kimse için hiçbirşey ifade etmez. Ancak tekrar HSM ‘in içine girdiğinde şifresi çözülerek anlamlı hale getirilebilir. Yada HSM ‘ler kendi aralarında güvenli bir kanal oluşturup keyleri birbirine klon yapabilirler.
Key ‘i silinmekten koruyan diğer yöntem de key seremonisi. Key ‘i ilk başta dışarıda parçalı halde oluşturtuyorsunuz. Yani güvendiğiniz 3–4 yada daha fazla kişiye belirli uzunlukta bir data oluşturmasını söylüyorsunuz. Herkes birbirinden habersiz sadece kendi datasını biliyor. Öncelikle bu dataları bir kağıda yazıp şifreli kasalarında saklıyorlar. Sonra herkesi sıra ile HSM ‘in başına getiriyorsunuz. Herkes kendi elindeki datayı HSM ‘e giriyor sonra HSM bu dataların tamamından bir key oluşturuyor.
(Bu parağrafı Fatih abinin uyarısı ile ekledim)
Buna ek olarak pin ile korunan smart kartlar içerisinde de keyler saklanabilir. Smartkart önce HSM ‘e takılıp bir pin ile ilklendirilir ve keyler smartkart içerisinde yedeklenir.
Bu 3 şekilde temper olmadan önce önleminizi alıp keylerimizi koruyoruz ki çok şükür bu sayede kredi kartlarımızı zırt pırt yeniden üretmek gerekmiyor.
Gelelim HSM tiplerine. Temelde 2 tipte HSM ‘imiz var. (Mantıksal olarak bir tip kabul edilse de CloudHSM ‘i bu tiplerin dışında tutuyorum. Serinin devamında özel bir yazı ile bahsedeceğim) 1. si genel amaçlı HSM ‘ler. PKCS11 dediğimiz bir standart var. (PKCS11 ‘e serinin devam eden yazılarında detaylı değineceğim) HSM üreticileri kendi HSM ‘leri ile konuşabilmek için pkcs11 standartındaki fonksiyonları içeren bir dll geliştiriyorlar. Bunun adı pkcs11 arayüzü. Siz bu dll ‘i uygulamanızda load ediyorsunuz ve pkcs11 arayüzündeki fonksiyonları kullanarak kriptolojik işlemleri HSM ‘e yaptırıp çıktılarını kullanıyorsunuz.
Peki, ben arduino kullanarak bir key ‘i sakladım bu işlemleri de bir dll üzerinden yapabiliyorum diyelim. (Ki adam burada bunu iddia etmiş) Hemen gidip bankalara bunu satabilir miyim? (Not: girişim tavsiyesi değildir). İşte bunun önüne geçmek için HSM ‘den istenen belgeler ve standartlar var. Mesela PCI, mesela CC, mesela FIPS. Bankalar ve ödeme kuruluşları düzenli olarak denetime giriyor ve HSM cihazlarından bunlara uyması bekleniyor. Bu standarlar o kadar katı ki DLL ile HSM arası mesajlaşma biçiminden HSM ‘in yan kanal ataklarına karşı korumalı olmasına kadar bir çok konuyu regule ediyor. Bu standartlar tüm türlerdeki HSM ler için geçerli.
Son olarak ülkemizde en çok kullanılan genel amaçlı HSM markaları: Safenet, Luna, Entrust, Utimacove Procrypt. Ayrıca Tübitak da direk ticari amaç gütmeyen genel amaçlı HSM ‘ler geliştiriyor. (Fatih abi Tübitak ‘ın HSM ‘ini satan bazı firmalar görmüş. Ayrıca ben de geçenlerde Tübitak ‘ın ödeme sistemeleri ile ilgili bazı geliştirmeler yaptığını işittim)
— — reklam mode on;
Procrypt bizim yerli ve milli ürünümüz. Diğer markalardan farklı olarak hem genel amaçlı hem ödeme sistemleri tipi olarak aynı anda kullanılabilyor.
— — reklam mode off;
İkinci tip hsm ‘imiz de ödeme sistemleri HSM. Bunlar adından da anlaşılacağı üzere banka altyapılarında kullanılan HSM ‘lerdir. Bu tip aslında bir nevi jenerik markadır. (Selpak ‘a selam olsun.) Thales (Payshield) firmasının yoğurt yeme tarzı ödeme sistemleri tipi HSM için standart haline gelmiştir desek herhalde yanlış olmaz. (Yanlışsa daha tecrübeli arkadaşlar yeşillendirsin.)
Bu tip HSM ‘ler iletişim için özel bir dll ‘e ihtiyaç duymaz. Kendileri ile direk bir port üzerinden TCP iletişime geçilebilir. Temelde encrypt/decrypt gibi basit fonksiyonları direk desteklemez. Bunun yerine iki harfli fonksiyonlara sahiptir. Fonksiyon adını ve gerekli parametreleri TCP mesaj içine koyar gönderirsiniz o da size işlemi yapıp cevabı döner. Bu fonksiyonlar genellike bankacılık işlemleri ile ilgilidir.
Mesela müşteriniz için yeni bir kredi kartı oluşturacaksınız diyelim. Siz kart numarasını ve son kullanma tarihini belirlersiniz. Bir de CVV koduna ihtiyacınız var. Bu kodu sizin keyinize göre hesaplayan fonksiyonun adı CW fonksiyonu. TCP mesaj içerisinde CW+keyiniz+kartno+son kullanma tarihi bilgilerini gönderirsiniz o size keyinizi kullanarak CVV kodu üretir ve verir. Siz de kodu fiziksel kart üzerine yazarsınız. Başka hiçbir yerde saklamanıza gerek yok. Sonra zaman geçti müşteri internet üzerinden alışveriş yapmak istiyor diyelim. Ödeme esnasında girdiği bilgiler sırası ile, internet sitesi ve bankalar arası kart merkezi aracılığı ile size kadar iletirlir. Siz de doğrulama için CY komutu ile (CY+keyiniz+kartno+son kullanma tarihi+CVV) HSM ‘e bu CVV doğrumu diye sorarsınız. Onay alırsanız işlemi gerçekleştirirsiniz değilse red yanıtı verirsiniz.
Biraz detaya girdim evet. Hemen bi üst katmana dönüyorum. Bu tip HSM ‘lerin genel amaçlı HSM ‘lerden diğer büyük farkı içeride key tutmamasıdır. Bunu biraz açalım. Genel amaçlı HSM ‘ler “bana key oluştur” dediğinizde içeride keyi oluşturup kaydeder ve size sadece “tamam oluşturdum” der. Ödeme sistemleri tipindeki HSM ‘ler ise “bana key oluştur” dediğinizde; sizin için bir key oluşturur ve kendi ana anahtarı ile bu oluşturduğu keyi şifreleyip, size şifreli halini döner ve bunu saklamanızı bekler. Yani içeride yalnızca kendi ana anahtarı (LMK: local master key) kayıtlıdır (+ LMK nın kendi ihtiyaç duyacağı keyler). Bu keyi yine temper mekanizması ile korur ve bu LMK hiçbir şekilde içeriden dışarı çıkartılamaz. Siz oluşturduğunuz key ile işlem yapmak isterseniz TCP mesajı içerisinde keyinizin şifreli halini de gönderirsiniz.
Mesela 2 önceki paragrafta CW komutu ile CVV kodu üretmiştik. İşte bu mesajın içerisinde gönderdiğiniz key aslında sizin gerçek keyinizin LMK ile şifreli hali. Siz TCP mesajı gönderdiğinizde içeride önce LMK ile keyinizi decrypt eder (yani clear hale çevirir). Sonra bu clear key ile diğer parametreleri de kullanarak CVV oluşturur ve size döner.
Peki benim üretilmiş keyleri DB de saklamam bir güvenlik açığı değil mi? Cevap veriyorum hayır. Çünkü benim DB de tuttuğum üretilmiş keyler aslında LMK ile şifrelenmiş datalar. LMK olmadan tamamen anlamsız. LMK da HSM dışına hiçbir şekilde çıkartılamadığı için tüm DB ‘miz açığa çıksa bile kimsenin işine yaramaz. Bu konuyu key tipleri ve algoritmalardan bahsettiğim 2. yazı da daha iyi anlayacağız.
He bir de soft HSM ‘ler var. Evet ismi tamamen açınca anlamsız bişey ortaya çıkıyo. (yazılımsal donanımsal güvenlik şeysi). Bazı yerlerde simulatör diye de geçiyo. Bazılarını dockerize olarak bile ayağa kaldırabiliyorsunuz. Genel amaçlı tipleri için yine bir dll dosyası var. Gerçek HSM gibi kullanıbiliyorsunuz. Yazılım geliştirme tarafı için çok kullanışlı. Her marka kendisi için ürettiği gibi bağımsız olarak geliştirimiş github repoları da mevcut.
Evet sevgili gönül dostları. Rahat uyuyabilirsiniz verileriniz bana emanet. En azından bu sektörde olduğum müddetçe. Saçlarım yeteri kadar kuruduğuna göre artık çıkabilirim. Salı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ı
Ayrıca bu yazıyı review eden Fatih abi ve Ozan beye teşekkür ediyorum :)
