---
# System prepended metadata

title: 1171 Genelge

---

## Genelge uyumluluğu için sunum outline

### 1 - Genel Mimari

> Öncelikle bankanın işlem imzalamada kullanılmak üzere, mobil uygulaması içinde 
bu işlemlere özgü güvenli bir ortam yaratmak ve BSEBY’nin 34 üncü maddesinin on
beşinci fıkrasından kaynaklanan yükümlülüklerini yerine getirmek üzere 
i. Spesifik bir Yazılım Geliştirme Kiti (SDK) ve 
ii. Doğrudan bu SDK ile güvenli ayrı bir kanaldan iletişim kuracak şekilde 
yapılandırılmış bir Güvenlik Sunucusu (SS)
oluşturması gerekmektedir

* SDK ve SS icin ilgili bilesenlerin adreslenerek genel mimari cizimi.
- [ ] amoprhie.flutter.shield ile ayri bir pakete ayrismasi
- [x] amoprhie.shield ile ayri bir pakete ayrilmasi


### 2 - Enrollment Sureci 
>İşlem imzalamada kullanılacak müşteriye özgü şifreleme gizli anahtarı ile buna 
karşılık gelen açık anahtarın(asimetrik anahtar çiftinin), müşterinin mobil bankacılık 
uygulamasının yüklü olduğu mobil cihazında bulunan ve asimetrik anahtar çifti 
oluşturabilen ve oluşturulan anahtar çiftlerinden şifreleme gizli anahtarını 
kopyalanmaya ve dışarıya çıkarılmaya imkan vermeyecek şekilde saklayabilen (iOS 
cihazlar için “Secure Enclave”, Andorid cihazlar için “hardware backed keystore” ya 
da “Strong Box” gibi) kriptografik donanım biriminde SDK tarafından oluşturulması 
ve SDK tarafından müşteriye özgü olarak oluşturulan şifreleme gizli anahtarının bu
donanım birimlerinde saklanması ve imzalama işlemi için yalnızca SDK tarafından 
kullanılabiliyor olması gerekmektedir. Şifreleme gizli anahtarının “müşteriye özgü” 
olması, müşteriye bağlanmış (binded) mobil cihaza ve o cihaz üzerindeki 
aktifleştirilmiş SDK örneğine (instance) özgülenmiş bir gizli anahtar olmasını ifade 
eder. Asimetrik anahtar çifti oluşturmada kullanılacak algoritmaların ve anahtar 
uzunluklarının, BSEBY’nin 9 uncu maddesinin ikinci fıkrası çerçevesinde günün 
teknolojine uygun olarak seçilmesi zorunludur.

* Enrollment sureci detayli
* Kullanilan algoritma ve teknikler
    * Mobil tarafta key generation
    * Server tarafina iletme
    * Serverda key uretme, clienta iletme
* Gateway processing sureci
    * JWS hash kontrolleri
    * mtls/sifreleme isleri

- [ ] Client tarafta asimetrik anahtar olusturma
- [ ] Client public key sunucuya iletme; grant flow ile ve saklama
- [ ] Server tarafta root certifika ile kuruluma anahtar olusturma
- [ ] Server public key istemciye iletme; grant flow ile ve saklama


### 3 - Device Kontrol & Imzalama
> SDK tarafından müşteri mobil cihazı üzerindeki kriptografik donanım birimine 
ürettirilen ve yalnızca SDK tarafından imzalama işleminde kullanılabilen müşteriye 
özgü şifreleme gizli anahtarı için gelecek “imzala işlemi taleplerinin” yalnızca 
SS’nin gerçekleştireceği güvenlik kontrolleri sonrası ve yalnızca 2. maddede 
belirtilen asimetrik anahtar çiftlerinden müşteriye özgü şifreleme gizli anahtarının 
diğer çifti olan müşteriye özgü açık anahtar ile şifrelenmiş bir şekilde müşteri için
aktifleştirilmiş SDK örneğine SS tarafından gönderilmesi sağlanmalıdır.

* transaction sureci detayli akis
* Kullanilan algoritma ve teknikler
    * encyiption
    * Workflow instacing ve authorization
* Gateway processing sureci
    * JWS hash kontrolleri
    * Decryption

- [ ] IHS sdk entegrayonunun yapilmasi
- [ ] Workflow Manager icerisinde ihs sdk fonksiyonu ile guvenlik kotnrollerinin yapilasi.
- [ ] transition body'nin client sertifika ile encript edilmesi


### 4 - amoprhie.flutter.shield & IHS

> SS’nin ilgili SDK örneğine imzalama talebinde bulunabilmesi için, ilgili SDK 
örneğinin arka planda sürekli bir şekilde çalışan güvenlik sensörleri yoluyla güvenli 
mobil uygulama ve güvenli mobil cihaz üzerinde çalıştığını teyit edecek güvenlik 
kontrollerini gerçekleştirmesi gerekmekte ve bu güvenlik sensörlerinden sağlanacak 
risk verileri SDK ile SS arasındaki tahsisli güvenli ayrı bir kanaldan (Out-of-Band)
SS’ye iletilmelidir.
SDK’nin güvenlik sensörleri, BSEBY’nin 34 üncü maddesinin on beşinci fıkrasına 
uygun olacak şekilde, sürekli bir biçimde asgari olarak aşağıdaki kontrolleri 
sağlayarak SS’ye iletilmek üzere gerekli risk verilerini oluşturmalıdır:
i. Mobil uygulama güvenilirliğinin ve bütünlüğünün bozulmasına ilişkin 
kontroller,
a) Hassas verilerin kullanıcı arayüzü üzerinden girilmesi esnasında 
çalınmasını engellemeye yönelik kontroller (anti-keylogging)
b) Çalışmakta olan SDK kodunun çalışma anında değiştirilmediğine 
ve araya zararlı kod parçalarının eklenmediğine ilişkin kontroller 
(anti-injection)
c) Çalışmakta olan SDK kodunun debugger ortamında, emülatör 
ortamında ya da sanal makinede çalışmakta olup olmadığına 
ilişkin kontroller (anti-debugging ve anti-emulation)
d) Aktive edilmiş mobil bankacılık uygulaması ve SDK’nin yalnızca 
aktivasyon sırasında kaydedilmiş mobil cihaz üzerinde çalıştığına 
ilişkin kontroller (device-binding)
ii. Mobil cihaz güvenilirliğinin ve bütünlüğünün bozulmasına ilişkin 
kontroller,
a) Mobil cihazın zararlı yazılım barındırıp barındırmadığı ya da bu 
yazılımlarca ele geçirilip geçirilmediğine ilişkin kontroller (antimalware),
b) Mobil cihaz işletim sisteminin kırılıp kırılmadığına (jailbreaking) 
ilişkin kontroller

* IHS urunnun yetkinlikleri ve calisma mekanizmasi
* flutter.shield sdk sinin ihs ile birlikte calismasi
* urunlerin end point bilgileri.

- [ ] flutter.shieldin ihs sdksi icerecek sekilde calismasi.


### 5 - Server Anahtarlari

> SS ile SDK arasındaki kanalın güvenliğinin sağlanabilmesi için, mobil bankacılık 
uygulaması ve SDK’nin ilk aktivasyonu sırasında, henüz aktive edilmemiş SDK 
örneği ile SS arasında SS’nin sunucu sertifikası yoluyla güvenli bir TLS bağlantısı
kurulması sağlanmalı ve sonrasında aktivasyonu gerçekleşen SDK örneği ve mobil 
cihaza özgü olacak şekilde SS tarafından üretilen asimetrik anahtar çiftlerinden 
şifreleme gizli anahtarının bu güvenli bağlantı üzerinden ilgili SDK örneğine 
iletilmesi ve SDK kontrolündeki güvenli bir alanda şifrelenmiş bir şekilde 
saklanması sağlanmalıdır. SS tarafından aktivasyonu gerçekleşen SDK örneği için 
üretilen asimetrik anahtar çiftlerinden “gizli” olanı SS tarafından saklanmamalı ve 
ilgili SDK örneğine iletilir iletilmez silinmeli, söz konusu anahtar çiftlerinden “açık” 
olanı ise SS tarafından imzalanarak ilgili SDK örneğine atanmış bir istemci 
sertifikasına dönüştürülmek suretiyle söz konusu güvenli bağlantı üzerinden ilgili 
SDK örneğine iletilmelidir. Bu adımlar sonrasında ilgili SDK örneği ile SS 
arasındaki iletişimde söz konusu sunucu ve istemci sertifikalarının kullanılması 
yoluyla çift yönlü kurulacak bir mTLS bağlantısı (Mutual TLS) üzerinden uçtan uca 
güvenli bir iletişim kanalının tesis edilmesi ve bu iletişim kanalının mobil bankacılık 
uygulaması ile banka arkayüzü (back-end) arasındaki iletişim kanalından ayrı ve 
yalnızca SS ve SDK arasındaki iletişime tahsisli güvenli ayrı bir kanal (Out-of-Band)
olarak yapılandırılması sağlanmalıdır. Asimetrik anahtar çifti oluşturmada 
kullanılacak algoritmaların ve anahtar uzunluklarının, BSEBY’nin 9 uncu 
maddesinin ikinci fıkrası çerçevesinde günün teknolojine uygun olarak seçilmesi 
zorunludur.

* Server anahtarlari olsuturma ve client iletisimi akisi
* Root sertifika saklama ve kullanim bilgileri
* Algoritma ve teknik detaylar
* Guvenli kanal - Servis endpoint bilgileri, nasil ayristigi.

- [ ] Security endpointler icin ayri bir apisix kurulumu mu acaba ?

### 6 - Login
> 7. Her bir SDK örneğinin(instance), ancak 5. maddede belirtilen güvenlik sensörleri 
üzerinden oluşturduğu risk verileri üzerinden SS’nin güvenilirlik ve bütünlük
kontrollerinden geçmiş olması kaydıyla, SS’nin kendisine atadığı istemci sertifikası
yoluyla 6. maddede belirtilen şekilde kurulmuş olan uçtan uca güvenli bir iletişim 
kanalı üzerinden, müşterinin girdiği PIN/bilinen unsuru için SS’e doğrulama isteği 
gönderebilmesi sağlanmalıdır.

> 8. Mobil bankacılık uygulaması ve SDK’nın ilk aktivasyonu sırasında, 
i. Müşterinin “bildiği unsur” olarak kullanacağı PIN ya da parolanın, SDK 
tarafından kriptografik özet (hash) haline dönüştürülerek SS’ye 
gönderilmesi ve bu kriptografik özetin tuzlanmış özet (salted-hash) haline 
dönüştürülerek SS veritabanında şifrelenmiş bir şekilde saklanması;
ii. Aktifleştirilmiş SDK örneğinin 2. madde uyarınca müşteriye özgü asimetrik 
anahtar çifti oluşturması ve bu anahtarlardan “açık” olanını SS’ye iletmesi,
iii. SS’nin aynı zamanda bir “Sertifika Otoritesi” rolü oynayarak, 
aktifleştirilmiş SDK örneği tarafından müşteriye özgü olarak kendisine 
iletilen açık anahtar için müşteriye özgü bir sertifika üretmesi, müşteri 
tarafından imzalanan içeriğin teyidi için bu sertifikayı kullanması ve SDK 
örneğinin kullanım dışı bırakılması gereken durumlarda söz konusu 
sertifikayı geçersiz hale getirmesi 
gerekmektedir

> 9. Sekizinci maddede belirtilen PIN/bilinen unsur bilgisi ya da bu unsura ilişkin kriptografik özet (hash) verisi SDK tarafında hiçbir şekilde saklanmamalı ve doğrulama isteğinin gönderilmesini müteakip derhal SDK tarafında silinmeli ve SS veritabanında da
PIN/bilinen unsur ya da bu unsura ilişkin kriptografik özet (hash) verisi hiçbir şekilde 
açık bir şekilde (plain text) saklanmamalı, söz konusu veritabanında SDK tarafından 
gönderilen hash verisi, tuzlanmış özet (salted-hash) haline dönüştürülerek SS 
veritabanında yalnızca şifrelenmiş bir şekilde tutulmalıdır.

> 10. SDK’nın SS’ye göndereceği PIN/bilinen unsur için doğrulama isteği, işbu Genelge
ekinde yer verilen açıklamaların 1.bölümünde de belirtildiği üzere ve BSEBY’nin 11 
inci maddesinin üçüncü fıkrasına uygun olarak, müşterinin girdiği PIN/bilinen 
unsurun hash halinin SS veritabanında bulunan salted-hash hali ile karşılaştırılması 
yoluyla çevrimiçi doğrulanmalıdır.


* Login akisi
* Passord Hashing teknik ve detaylari
* DB level passpord store teknik ve detaylari

- [ ] Client tarafinda passwordung haslenerek iletilmesi.


### 7 - Islem Guvenligi 

> 11. Müşterinin PIN/bilinen unsur doğrulama işleminin 10. maddede belirtildiği şekilde 
başarıyla gerçekleşmesi halinde, 
i. SS ve SDK arasındaki tahsisli güvenli kanal üzerinden SS’nin 3. ve 8.
maddede belirtilen müşteriye özgü sertifikadaki açık anahtar ile şifrelenmiş 
bir şekilde SDK’ye kimlik doğrulamaya yönelik bir “işlem imzalama talep 
mesajı” (challenge) göndermesi,
ii. SDK tarafından alınan bu mesajın ise müşteri mobil cihazının kriptografik
donanım biriminde bulunan müşteriye özgü şifreleme gizli anahtarı ile 
açılmak suretiyle, SDK’nın kimlik doğrulamaya yönelik bir “işlem 
imzalama onay mesajını” (response) aynı anahtarla imzalayarak kimlik 
doğrulamaya yönelik bir doğrulama kodu oluşturması ve bunu SS’e 
göndermesi,
iii. SS’in, SDK’dan kendisine iletilen doğrulama kodunu müşteriye özgü açık 
anahtar ile açarak doğruluğunu teyit etmesi,
iv. Teyit edilmiş doğrulama kodu için SS’in banka arkayüzü (back-end) ile 
arasındaki uçtan uca güvenli iletişim kanalından back-end’e kullanıcıyı 
içeriye alması (login) yönünde mesaj iletilmesi ve bu mesaj sonrasında
back-end’in kullanıcıyı içeriye alması (login) ,
v. Bu aşamaların tamamlanmasını müteakip ilgili doğrulama kodu için zaman 
damgası oluşturularak banka log sunucusuna aktarılması 
sağlanmalıdır. Challenge-Response mesajlarının tekrarlama (replay) saldırılarını 
engellemek üzere tek kullanımlık bir değer (nonce) içermesi zorunludur.
> 12. Müşteri mobil cihazının kritptografik donanım biriminde bulunan ve yalnızca 
aktifleştirilmiş SDK örneği tarafından kullanılabilen müşteriye özgü şifreleme gizli 
anahtarı yoluyla,
i. SDK tarafından üretilen kimlik doğrulamaya yönelik doğrulama kodunun,
ii. SDK tarafından müşteriye gösterilen bilgiler üzerinden müşterinin 
onayladığı tutar ve alıcı bilgisine göre spesifik olacak şekilde, SDK 
9
tarafından finansal sonuç doğuran işlemler için üretilen doğrulama 
kodunun,
iii. SDK tarafından müşteriye gösterilen bilgiler üzerinden müşterinin onayını 
ve irade beyanını yansıtan elektronik ortamda kurulacak sözleşmelerin
müşteri tarafından elektronik imzalı olarak imzalanması sağlanmalıdır.

> 13. onikinci madde çerçevesinde finansal sonuç doğuran işlemler ile elektronik ortamda 
sözleşme kurulmasına ilişkin (12.ii ve 12.iii) SDK tarafından imzalanmak üzere 
müşteriye içerik gösterilmesi öncesinde, müşterinin başlattığı işlemlerin mobil 
bankacılık uygulaması tarafından öncelikle back-end sunucusuna iletilmesi ve backend sunucusunun bu müşteri talebini doğrulanmak üzere uçtan uca güvenli kanaldan 
SS’e iletmesi gerekmektedir. Back-end’den SS’e müşteri talebinin iletilmesi 
sonrasında bu talebe ilişkin;
i. SS ve SDK arasındaki tahsisli güvenli kanal üzerinden SS’nin 3. ve 8.
maddede belirtilen müşteriye özgü sertifikadaki açık anahtar ile şifrelenmiş 
bir şekilde SDK’ye “işlem imzalama talep mesajı” (challenge) göndermesi, 
ii. SDK tarafından alınan bu mesajın ise müşteri mobil cihazının kritptografik 
donanım biriminde bulunan müşteriye özgü şifreleme gizli anahtarı ile 
açılmak suretiyle ve yine SDK tarafından müşteriye gösterilecek şekilde bir 
onay ekranı çıkarması, 
iii. SDK tarafından müşteriye gösterilen onay ekranındaki bilgilerin müşteri 
tarafından onaylanması halinde, onaylanan bu bilgiler için SDK’nın,
müşteriye özgü şifreleme gizli anahtarı ile “işlem imzalama onay mesajını”
(response) imzalayarak bir doğrulama kodu oluşturması ve bunu SS’e 
göndermesi,
iv. SS’in, SDK’dan kendisine iletilen doğrulama kodunu müşteriye özgü açık 
anahtar ile açarak, back-end’den iletilen bilgiler ile karşılaştırmak suretiyle 
bu bilgilerin değişmediğine ilişkin bütünlük kontrolünü gerçekleştirmesi ve 
bilgilerin doğruluğunu teyit etmesi,
v. Teyit edilmiş doğrulama kodu için SS’in banka arkayüzü (back-end) ile 
arasındaki uçtan uca güvenli iletişim kanalından back-end’e ilgili işlemi 
gerçekleştirmesi yönünde mesaj iletilmesi ve bu mesaj sonrasında backend’in kendisi için doğrulama kodu oluşturulmuş işlemi gerçekleştirmesi,
vi. Bu aşamaların tamamlanmasını müteakip ilgili doğrulama kodu için zaman 
damgası oluşturularak banka log sunucusuna aktarılması 
sağlanmalıdır. Challenge-Response mesajlarının tekrarlama (replay) saldırılarını 
engellemek üzere tek kullanımlık bir değer (nonce) içermesi zorunludur


* Transaction flow detayli akisi (workflow transition)
* anahtarlarin kullandigi noklara, ency/decr icin
* nonce, change/response akisi
* Dogrulama kodu (mobile push/otp) mekanizmasi, sub flow akisi


### 8 - Access & Refresh Token


> 14. x10. madde çerçevesinde PIN/bilinen unsurun doğrulaması, 11. madde çerçevesinde 
de müşterinin sahip olduğu unsur niteliğindeki müşteriye özgü şifreleme gizli 
anahtarı yoluyla geçerli bir doğrulama kodu oluşturulması sonrasında gerçekleşecek 
iki bileşenli kimlik doğrulamaya dayalı login işlemini müteakip açılan kullanıcı 
oturumunun geçerli olduğu süre boyunca,
i. SDK tarafından müşteriye gösterilen bilgiler üzerinden müşterinin 
onayladığı tutar ve alıcı bilgisine göre spesifik olacak şekilde, SDK 
tarafından finansal sonuç doğuran işlemler için üretilen doğrulama 
kodunun,
ii. SDK tarafından müşteriye gösterilen bilgiler üzerinden müşterinin onayını 
ve irade beyanını yansıtan elektronik ortamda kurulacak sözleşmelerin 12. maddeye uygun olarak müşteriye özgü şifreleme gizli anahtarı ile imzalanması 
sürecinde müşterinin yeniden PIN/bilinen unsur doğrulaması yapması 
gerekmemektedir. BSEBY’nin 39 uncu maddesinin üçüncü fıkrası uyarınca 
müşterinin iki bileşenle kimlik doğrulama gerçekleştirerek açtığı son oturumun 
üzerinden 90 günden daha fazla bir süre geçmemiş olması kaydıyla yalnızca sahip 
olunan kimlik doğrulama unsuru ile gerçekleştirilebilen işlemler için PIN/bilinen 
unsur doğrulamasının tekrar yapılması gerekmemekle birlikte, söz konusu fıkra 
uyarınca gerçekleştirilecek login işlemleri ile finansal sonuç doğuran işlemler için 
müşteriye özgü şifreleme gizli anahtarı yoluyla 11. ve 13. maddelere uygun olarak 
doğrulama kodu oluşturulması zorunludur.


* Access ve refresh token bilgileri. exp, claimler
* Lifecyle akisi
* 90 gun kontrolu, cihaz eslestirme kaldirma detaylari
* jwt validation, outh2 konulari
* teknik bilgiler rfc ler
* ency/decry

### 9 - Document Signing
> 14. Madde ..... https://www.bddk.org.tr/Mevzuat/DokumanGetir/1171

* Contrat akisi/altyapisi
* Pades
* Zaman damgasi