## 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