Hile Senaryoları ve Karşı Önlemler

32 senaryo. Her biri için: saldırı, karşı önlem, kalan risk ve Faz 8 kırmızı takım testi. Bu belge dürüst olmak zorundadır — "engellendi" yazamadığımız yere KISMEN veya AÇIK yazılır.

Efor ölçeği: 🟢 önemsiz (herkes yapabilir) · 🟡 orta (biraz teknik bilgi) · 🔴 yüksek (root/tersine mühendislik) · ⚫ çok yüksek (koordineli, uzman)

0. Tehdit modeli — güven sınırı nereye taşındı

v1.0'da (öğretmen sınıfı tarar) güven sınırı öğretmenin cihazındaydı ve öğrenci cihazı hiç güvenilmiyordu. Bu güvenliydi ama hukuken ve teknik olarak çalışmıyordu.

v2.0'da (1:1 öğrenci cihazında) doğrulama kararı öğrencinin kontrolündeki bir cihazda veriliyor. Bu, klasik bir "istemciye güvenme" problemidir ve dürüstçe adı konmalıdır:

Tamamen ele geçirilmiş bir cihazda, istemci tarafı hiçbir doğrulama mutlak değildir.

Bu yüzden mimari şu ilke üzerine kurulur:

Sunucu, doğrulamanın sonucuna güvenmez; doğrulamanın koşullarına güvenir.

Yani sunucu şunu sormaz: "cihaz 'doğrulandı' dedi mi?" Şunu sorar: "bu 'doğrulandı' iddiası, (a) bütünlüğü kanıtlanmış bir cihazdan, (b) değiştirilmediği kanıtlanmış bir uygulamadan, (c) kurcalanmadığı kanıtlanmış bir şablonla, (d) doğru zamanda ve doğru yerde üretilmiş mi?"

Dördü birden sağlanamıyorsa fail-closed: öğrenci Y1'den düşürülür, Y4 (öğretmen cihazında) veya Y3 (manuel) yoluna yönlendirilir. Sistem asla "emin değilim ama var sayayım" demez.

Ve son katman insandır: öğretmen nokta denetimi. Kriptografinin çözemediği her şeyi olasılıksal olarak yakalar.

1. Kimlik devri saldırıları

S1 — Telefonu arkadaşa verme 🟢

Saldırı: Öğrenci A derse gelmez, telefonunu B'ye verir. B, A'nın telefonundan yoklama yapar.

Karşı önlem: 1:1 yüz doğrulama. B'nin yüzü, cihazda saklı A'nın şablonuyla eşleşmez → doğrulama başarısız.

Kalan risk: Y2 (biyometrisiz alternatif) ve Y5 (QR/PIN) yöntemlerinde AÇIK — bu yöntemler kimliği değil cihazı doğrular. Telafi: bu yöntemleri kullanan öğrenciler nokta denetimi rastgele seçiminde ağırlıklandırılır (örn. 3×). Bu bir cezalandırma değil, güven farkının istatistiksel telafisidir ve KVKK'nın "kısıtlama olmaksızın alternatif" şartını ihlal etmez (öğrenci için ek adım veya gecikme yoktur).

Y3'te de AÇIK ve bu en zayıf noktadır: öğretmen "bu öğrenci derste" diye beyan eder; öğrencinin hiçbir katılımı gerekmez, dolayısıyla telefonu arkadaşına veren öğrenci için Y3 bir engel bile değildir. Karşı önlem güvenlik değil şeffaflıktır: source=manual, zorunlu gerekçe ve panelde manuel oran raporu (ADR-007 §3.2).

Y4 bu boşluğu kısmen kapatır (12.09.2026, ADR-024). Y4 kaydı, öğrencinin kendi kimlik doğrulanmış oturumundan açtığı bir istek olmadan yazılamaz ve öğretmen karşısındaki kişiyi ad + numara ile teyit eder. Yani A'nın telefonunu alan B, Y4 yolunu kullanmak isterse A'nın hesabından istek açmak ve sonra A olarak öğretmenin karşısına çıkmak zorundadır — Y3'te böyle bir zorunluluk yok.

Y4'te kalan risk — açıkça: teyit öğretmenin gözüdür, yüz eşleştirmesi değil. Öğretmen 200 kişilik bir sınıfta öğrencilerini tanımıyorsa ve known_student dayanağını işaretliyorsa, Y4'ün güvencesi Y3'e yaklaşır. Bu yüzden dayanak kodu kayda yazılıyor ve raporlanabiliyor: hangi öğretmenin neye dayanarak teyit ettiği ölçülebilir. Bu da bir güvenlik önlemi değil, şeffaflık mekanizmasıdır.

Test: İki gönüllü, A'nın cihazıyla B doğrulamayı denesin. Beklenen: reddedilir, anomalies tablosunda kayıt yok (normal başarısızlık), 3 art arda başarısızlıkta öğretmene bildirim.

S2 — Öğrenci kartını (MIFARE/RFID) arkadaşa verme 🟢

Saldırı: Klasik kart tabanlı sistemlerin temel zafiyeti.

Karşı önlem: Sistemde kart yoktur. Bu saldırı yüzeyi mimari olarak mevcut değil.

Not: Kurum, kart okuyucularını bina girişinde kullanmaya devam edebilir; bunu tamamlayıcı sinyal olarak içe aktarabiliriz ama asla tek başına yoklama kanıtı sayılmaz. MIFARE Classic'in kriptografisi 2008'den beri kırık (ESORICS 2008, IEEE S&P 2009) ve 2024'te donanım seviyesinde arka kapı bulundu (IACR ePrint) — kart tabanlı yoklama güvenlik açısından savunulamaz.

Test: Uygulanamaz.

S3 — Arkadaşının fotoğrafını gösterme (print attack) 🟢

Saldırı: B, A'nın basılı fotoğrafını A'nın telefonunun kamerasına tutar.

Karşı önlem: MiniFASNetV2 pasif canlılık modeli (Silent-Face). Yayınlanan performans: TPR %97,8 @ FPR 1e-5, Snapdragon 845'te 24 ms. Kritik avantaj: v1.0'da bu model 40 px'lik uzak bir yüzde çalışacaktı (anlamsız); v2.0'da selfie mesafesinde 250-400 px'lik bir yüzde çalışıyor — doku, moire ve yansıma ipuçları tam olarak mevcut.

Gerçeklik kontrolü: Aralık 2025'te Wenzhou'da (Çin) çalışanlar iş arkadaşlarının yüzlerini yazdırıp maske yaparak canlılık kontrolü olmayan bir sistemi kandırdı. Canlılık opsiyonel değildir.

Kalan risk: Yüksek kaliteli baskı + iyi ışık kombinasyonunda %2,2 kaçırma. Aktif meydan okuma (rastgele "başınızı hafifçe sağa çevirin") ile daraltılır.

Test: 300 dpi renkli baskı, mat ve parlak kâğıt, 3 farklı ışık koşulu, 20 deneme. Beklenen: ≥19 reddedilir.

S4 — Video replay 🟡

Saldırı: B, A'nın videosunu başka bir ekranda oynatıp kameraya tutar.

Karşı önlem: Canlılık modeli ekran replay sınıfını ayrıca tespit eder (3-sınıf softmax: live/print/replay). Moire deseni + ekran parlaklık spektrumu + kare hızı beat frekansı. Ek olarak aktif meydan okuma: sistem rastgele bir hareket ister; kayıtlı video buna cevap veremez.

Kalan risk: Yüksek yenileme hızlı OLED ekran + doğru açı ile zorlaşır. Aktif meydan okuma bu senaryoyu pratikte kapatır.

Test: 60 Hz ve 120 Hz ekranda replay, 20 deneme. Beklenen: ≥19 reddedilir; aktif meydan okuma açıkken 20/20.

S5 — 3D maske / silikon maske 🔴

Saldırı: A'nın yüzünün 3D basılmış maskesi.

Karşı önlem: MiniFASNet 3D maske sınıfını kısmen kapsar. Aktif meydan okuma (mikro ifade, göz kırpma) yardımcı olur.

Kalan risk: KISMEN. Yüksek kaliteli silikon maskeler pasif RGB canlılığını atlatabilir. Ancak maliyet (yüzlerce dolar + A'nın 3D yüz taraması) bu saldırıyı ders yoklaması için ekonomik olmaktan çıkarır. iOS'ta TrueDepth (ARKit) kullanılabilen cihazlarda derinlik doğrulaması eklenerek daraltılır — ancak bunu zorunlu kılmak Android'de eşdeğeri olmadığı için ayrımcılık yaratır, o yüzden opsiyonel güçlendirme olarak kalır.

Test: Bütçe elverirse bir maske ile; yoksa senaryo TEST EDİLMEDİ olarak raporlanır. Dürüstlük şartı: test edilmeyen senaryo "engellendi" diye yazılmaz.

S18 — Kayıt aşamasında arkadaşının yüzünü kaydettirme 🟡

Saldırı: A, kayıt (enrollment) sırasında B'nin yüzünü kaydettirir. Sonra B, A adına sürekli yoklama yapabilir. Bu, sistemin en kritik tek noktasıdır — burası kırılırsa geri kalan her şey çöker.

Karşı önlem — enrollment politikasına göre:

Öneri: Varsayılan SUPERVISED. SELF_ENROLLED kullanılacaksa, ilk dersteki nokta denetiminde yeni kayıtlı öğrenciler %100 oranında seçilir.

Kalan risk: SELF_ENROLLED'da yönetici dikkatsizliğine bağlı.

Test: Her politika için gönüllü çiftle deneme.

S19 — İkiz kardeş / çok benzeyen kardeş 🟢

Saldırı: Tek yumurta ikizi A'nın telefonuyla doğrulama yapar.

Karşı önlem: Tek yumurta ikizleri hiçbir yüz tanıma sistemi güvenilir biçimde ayıramaz. NIST FRTE Part 2 bunu açıkça söylüyor: "twins will very often produce a high-scoring non-match on a candidate list and a false alarm." İkizler doğumların %3,3'ü.

Karşı önlem — dürüst yaklaşım: Sistem bunu çözmeye çalışmaz. Bunun yerine:

1. Kayıt sırasında kurum, ikiz/kardeş ilişkisini işaretleyebilir (sibling_group_id).
2. İşaretli öğrenciler nokta denetiminde ağırlıklandırılır.
3. Aydınlatma metninde bu sınırlama açıkça yazılır.

Kalan risk: AÇIK. Bu, teknolojinin bilinen ve kabul edilen sınırıdır; gizlenmeyecek.

Test: Mümkünse gönüllü ikiz çiftle ölçüm; sonuç ne olursa olsun raporlanır.

2. Cihaz ve yazılım bütünlüğü saldırıları

Bu bölüm v2.0 mimarisinin ana savaş alanıdır. Yüz sahteciliği artık kolay saldırı değil; asıl saldırgan cihazı hedefler.

S26 — Cihazda saklanan yüz şablonunu değiştirme (template tampering) 🔴 ⭐

Saldırı: A, telefonunu root'lar, uygulamanın veri dizinindeki şablonu bulur ve B'nin şablonuyla değiştirir. Artık B, A'nın telefonundan doğrulama yapabilir. Veya A, şablonu öyle bir değiştirir ki basit bir fotoğraf eşleşir.

Bu, 1:1 cihaz-üstü mimarinin en ciddi tehdididir ve çok katmanlı savunma gerektirir:

Katman 1 — Şablon hiçbir zaman açıkta durmaz

Şablon, StrongBox (Android) / Secure Enclave (iOS) içinde üretilen, dışa aktarılamaz bir AES-256 anahtarıyla şifrelenmiş olarak saklanır. Anahtar:

• setIsStrongBoxBacked(true) — mümkünse ayrı güvenlik yongasında
• setInvalidatedByBiometricEnrollment(true) — cihaza yeni parmak izi/yüz eklenirse anahtar geçersizleşir
• setUnlockedDeviceRequired(true) — cihaz kilitliyken kullanılamaz
• Uygulama silinirse anahtar donanımdan silinir → şablon kurtarılamaz

Root'lu bir cihazda dosya okunabilir ama şifreli bir bloktur ve anahtar donanımdan çıkarılamaz.

Katman 2 — Şablon taahhüdü (commitment) ⭐ ana savunma

Kayıt anında cihaz şunu hesaplar ve sunucuya gönderir:

salt        = 32 rastgele bayt
commitment  = SHA-256( template_bytes || salt || student_id || model_version )

Sunucu commitment ve salt'ı saklar. Şablonun kendisini değil.

Her doğrulamada cihaz, o an fiilen kullandığı şablondan taahhüdü yeniden hesaplayıp kanıta ekler. Sunucu kayıtlı taahhütle karşılaştırır:

• Eşleşiyorsa → kayıt anındaki şablonla aynı şablon kullanılmış ✅
• Eşleşmiyorsa → şablon değişmiş → anomalies: template_mismatch → Y1 kapatılır, öğrenci gözetimli yeniden kayda yönlendirilir ⛔

Neden bu KVKK açısından güvenli: commitment bir SHA-256 çıktısıdır. Geri çevrilemez, başka bir yüzle eşleştirilemez, hiçbir tanıma faydası yoktur — yalnızca eşitlik kontrolü yapar. Biyometrik şablon değil, bir bütünlük etiketidir. (Yine de aydınlatma metninde açıkça beyan edilecek.)

Katman 3 — Uygulama bütünlüğü (bu olmadan Katman 2 atlatılır)

Kurcalanmış bir uygulama, yeni şablonu kullanıp eski taahhüdü gönderebilir. Bunu engelleyen:

Android — Donanım Anahtar Attestation'ı. İmzalama anahtarı StrongBox'ta üretilir ve attestKey ile bir sertifika zinciri çıkarılır. Zincir Google'ın kök sertifikasına kadar doğrulanır ve şunları kriptografik olarak kanıtlar:

• verifiedBootState = Verified → bootloader kilitli, custom ROM yok
• attestationApplicationId → uygulamanın paket adı + imzalama sertifikası hash'i
• osPatchLevel → güncel yama seviyesi
• Anahtarın donanımda üretildiği ve dışa aktarılamaz olduğu

Yamalanmış bir APK'nın imzalama sertifikası farklıdır → attestation reddedilir. Root'lu cihazda verifiedBootState Verified değildir → reddedilir.

iOS — App Attest. DCAppAttestService ile aynı garanti: uygulamanın gerçek, App Store'dan gelen, değiştirilmemiş bir kopya olduğu Apple tarafından onaylanır.

Ek katman — Play Integrity API: sunucu tarafında MEETS_STRONG_INTEGRITY (donanım destekli) talep edilir. MEETS_BASIC_INTEGRITY yeterli sayılmaz.

Katman 4 — İmzalı kayıt sertifikası

Gözetimli kayıt sırasında sunucu şunu imzalar:

enrollment_cert = sig_server( student_id, device_key_pub, commitment,
                              model_version, enrolled_by, timestamp )

Cihaz her doğrulamada bu sertifikayı sunar. Sahtesini üretmek sunucunun özel anahtarını gerektirir. Sessiz yeniden kayıt imkânsızdır — taahhüdü değiştirmek yeni bir sertifika gerektirir, o da yetkili gözetimi gerektirir.

Katman 5 — Anomali izleme

template_mismatch, attestation_fail, device_rebind, boot_state_degraded olayları anomalies tablosuna yazılır ve panelde admin'e gösterilir. Bir öğrencide art arda oluşması insan incelemesi tetikler.

Katman 6 — İnsan: nokta denetimi

Yukarıdaki her şey atlatılsa bile, öğretmene "A sınıfta mı?" sorulur. A yoksa yakalanır.

Kalan risk — dürüst değerlendirme: ⚫ KISMEN. Şu koşulların hepsini birden sağlayan bir saldırgan başarılı olabilir: (a) donanım destekli keystore'da bir açık bulmak veya attestation zincirini kırmak, (b) uygulamayı yamalamak, (c) şablonu değiştirmek, (d) nokta denetimine denk gelmemek. Bu, bir ders yoklaması için orantısız bir maliyet — ki güvenliğin amacı da budur: hileyi imkânsız kılmak değil, ekonomik olmaktan çıkarmak.

Kritik tasarım kuralı: Attestation başarısız olursa sistem fail-closed çalışır. Öğrenci "geçersiz" sayılmaz — Y4 (öğretmen cihazında doğrulama) veya Y3 (manuel) yoluna yönlendirilir. Cezalandırma yok, güvenilmeyen kanal kapatılır.

Test: Rootlu Pixel + Magisk + Frida hook denemesi; yamalanmış APK; emülatör. Beklenen: 3/3 attestation reddi, Y1 kapatılır, Y4'e düşülür, anomalies kaydı oluşur.

S9 — Root/jailbreak + uygulama yamalama ("verified = true" enjeksiyonu) 🔴

Saldırı: Öğrenci uygulamayı tersine mühendislikle açıp doğrulama fonksiyonunu her zaman true döndürecek şekilde yamalar. Yüze hiç ihtiyaç kalmaz.

Karşı önlem: S26 Katman 3 ile aynı — donanım anahtar attestation'ı + App Attest + Play Integrity. Yamalı uygulama farklı imzalama sertifikasına sahiptir; attestation zinciri bunu kriptografik olarak açığa çıkarır. Ek olarak:

• Kritik doğrulama mantığı native (C++) katmanda, Dart'ta değil — tersine mühendislik maliyetini artırır (obfuscation, güvenlik değil geciktirmedir; tek başına güvenilmez)
• İmzalama anahtarının kullanımı, canlılık ve eşleşme skorlarının native katmanda üretilmiş olmasına bağlanır

Kalan risk: ⚫ Gelişmiş saldırgan için azaltılmış, sıfırlanmamış. Nokta denetimi son savunma.

Test: Frida ile verify() fonksiyonunu hook'lama denemesi. Beklenen: attestation reddi.

S8 — Emülatörde çalıştırma 🟡

Saldırı: Uygulama bir Android emülatöründe çalıştırılır; sanal kamera ile A'nın videosu beslenir.

Karşı önlem: Play Integrity MEETS_DEVICE_INTEGRITY emülatörü reddeder. Donanım anahtar attestation'ı emülatörde üretilemez (gerçek TEE yok). BLE yakınlık zaten fiziksel cihaz gerektirir.

Kalan risk: Düşük.

Test: Android Studio emülatörü + Genymotion. Beklenen: 2/2 red.

S6 — Sanal kamera enjeksiyonu / deepfake 🔴

Saldırı: Cihaz kamera akışına gerçek kamera yerine üretilmiş bir video enjekte edilir.

Bağlam — bu tehdit hızla büyüyor. iProov Threat Intelligence Report 2025:

• Native sanal kamera saldırıları %2.665 arttı (2024)
• Face swap saldırıları %300 arttı ve artık canlılık tespiti kullanan sistemleri hedefliyor
• 115.000'den fazla saldırı kombinasyonu belgelendi; ~24.000 kullanıcı saldırı araçlarını suç pazarlarında satıyor
• Yeni vektör: image-to-video dönüştürme, "mevcut birçok canlılık tespit çözümünü aşabilir"

Karşı önlem:

1. Mimari avantaj: iProov'un verisine göre birincil hedef, görüntüyü sunucuya yükleyen sistemlerdir. Bizde görüntü hiç cihazdan çıkmaz; enjeksiyon için cihazın kendisinin ele geçirilmesi gerekir → S9/S26 savunmaları devreye girer.
2. Kamera donanım kontrolü: CameraCharacteristics ile fiziksel kamera doğrulama, sanal kamera HAL'lerinin reddi
3. Attestation (sanal kamera kurulumu genelde root gerektirir)
4. Aktif meydan okuma — rastgele, önceden bilinmeyen hareket isteği; önceden üretilmiş videoyla cevaplanamaz

Kalan risk: ⚫ İzlenmeli. Bu, en hızlı gelişen tehdit sınıfı; canlılık modeli güncellemesi için sürekli bakım planlanmalı.

Test: Sanal kamera uygulamasıyla enjeksiyon denemesi (root'lu cihazda).

S24 — Uygulamayı silip yeniden kurarak yeni cihaz bağlama 🟡

Saldırı: Öğrenci uygulamayı siler, arkadaşının telefonuna kurar ve kendi hesabıyla girip yeni şablon oluşturur.

Karşı önlem: Cihaz bağlaması sunucuda tutulur. Yeni cihaz kaydı:

• Bir öğrenci için aynı anda tek aktif cihaz
• Cihaz değişikliği SUPERVISED yeniden kayıt gerektirir (yetkili onayı)
• Soğuma süresi (örn. 24 saat) ve admin bildirimi
• Sık cihaz değişimi anomalies: frequent_device_rebind üretir

Kalan risk: Meşru cihaz değişimi (telefon kaybı/değişimi) sürtünme yaratır — bu kabul edilen bir maliyettir; yılda birkaç kez olan bir işlem için gözetimli kayıt makul.

Test: Cihaz değişimi denemesi. Beklenen: yetkili onayı olmadan Y1 açılmaz.

3. Yakınlık ve zaman saldırıları

S11 — Röle (relay) saldırısı ⚫ ⭐ en zorlu senaryo

Saldırı: A evde. Sınıftaki arkadaşı B, çapanın yayınladığı nonce'u (BLE'den okuyup veya QR'ı fotoğraflayıp) WhatsApp/internet üzerinden A'ya gönderir. A evde doğrulama yapar ve imzalı kanıtı geri gönderir.

Bu, mimarinin en zayıf noktasıdır ve kriptografiyle tam çözülemez.

Karşı önlemler:

1. Kısa nonce ömrü. Nonce 1,5 sn'de bir döner ve ≤5 sn içinde kullanılmalıdır. Röle zincirinin (oku → ilet → doğrula → geri ilet → gönder) bu pencereye sığması gerekir. Yüz doğrulaması tek başına 2-3 sn sürer → pencere pratikte çok dar.
2. RSSI aralık kontrolü. Öğrenci cihazı, çapadan aldığı sinyal gücünü kanıta ekler. Sınıf içi makul aralığın (örn. −40 ile −85 dBm) dışındaki değerler işaretlenir. ⚠️ RSSI sahtelenebilir bir alandır — root'lu cihazda değiştirilebilir; bu yüzden tek başına kanıt değil, tutarsızlık sinyalidir.
3. Zaman tutarlılığı. Nonce üretimi ile kanıt alınması arasındaki süre çapa tarafından ölçülür (cihazın kendi saatine güvenilmez).
4. ⭐ Öğretmen nokta denetimi. Asıl savunma budur. Her turda sistem 3-5 öğrenciyi rastgele seçer ve öğretmene sorar: "Ayşe Y. sınıfta mı?" Öğretmen bakar, onaylar veya reddeder. 60 kişilik sınıfta tur başına 5 kişi seçilirse, 3 turda bir öğrencinin en az bir kez seçilme olasılığı %23; röle yapan öğrenci yakalandığında akademik usulsüzlük süreci başlar. Caydırıcılık matematiksel değil, olasılıksaldır — ama kâğıt yoklamada bu olasılık sıfırdır.

Kalan risk: ⚠️ KISMEN — açıkça belgelenecek. Röle saldırısı, tüm yakınlık tabanlı sistemlerin ortak zafiyetidir (BLE, QR, WiFi, GPS — hepsi). Bizim farkımız, onu kabul edip insan denetimiyle telafi etmemiz.

Gelecek araştırma (§17): BLE distance bounding protokolleri, UWB (destekleyen cihazlarda cm hassasiyetli mesafe), ultrasonik yakınlık (mikrofon üzerinden, ses hızı ışık hızından 10⁶ kat yavaş olduğu için röle gecikmesi ölçülebilir hale gelir). Ultrasonik yaklaşım en umut verici olanı ve akademik olarak da yayınlanabilir bir katkı olabilir.

Test: İki cihaz, biri sınıfta biri binanın dışında, nonce'u manuel aktararak deneme. Beklenen: zaman penceresi çoğu denemeyi reddeder; geçenler nokta denetiminde yakalanır. Sonuç dürüstçe yüzdeyle raporlanır.

S25 — Kapının hemen önünde doğrulama 🟢

Saldırı: Öğrenci sınıfa girmez, kapının dışında BLE menzilinde durup doğrular ve gider.

Karşı önlem: RSSI eşiği kapı mesafesini dışarıda bırakacak şekilde kalibre edilir (derslik boyutuna göre politika parametresi). Ayrıca rastgele çoklu tur — öğrencinin ders boyunca kapıda beklemesi gerekir ki bu zaten "sınıfta olmak"tan farksız bir maliyettir. Nokta denetimi kesin çözer.

Kalan risk: Düşük.

S12 — QR ekran görüntüsü paylaşma 🟢

Saldırı: Sınıftaki öğrenci QR'ın ekran görüntüsünü alıp dışarıdakine gönderir.

Karşı önlem: QR animasyonlu — 1,5 saniyede bir yenilenir. Ekran görüntüsü gönderilene kadar geçersizleşir. (Akademik literatür de bu karşı önlemi öneriyor: saniyede 2 QR üreten "animated QR code".) Statik QR kullanan Proliz, UBYS, Qwickly gibi rakiplerin doğrudan zafiyeti budur.

Kalan risk: S11'e indirgenir (canlı ekran paylaşımı = röle).

S13 — BLE MAC spoofing / advertisement replay 🔴

Saldırı: Saldırgan çapanın BLE reklamını kaydedip kendi cihazından tekrar yayınlar; öğrenciler sınıf dışında da çapa görür.

Karşı önlem: Reklam içeriği HMAC(oturum_anahtarı, sayaç) ile üretilir. Saldırgan eski bir nonce'u tekrar yayınlayabilir ama sunucu/çapa tazelik kontrolü yapar → reddedilir. Yeni geçerli nonce üretmek oturum anahtarını gerektirir, o da öğretmen cihazının güvenli deposundadır.

Kalan risk: Düşük — replay engellenir; canlı röle S11'e girer.

S14 — GPS/konum sahteciliği 🟢

Saldırı: "Fake GPS" uygulamasıyla konum sahtelenir.

Karşı önlem: Sistem birincil kanıt olarak GPS kullanmaz. Konum, yalnızca zayıf bir tutarlılık sinyalidir (kampüs poligonu içinde mi). GPS sahteciliği kolay ve yaygın olduğu için bunun üzerine güvenlik inşa edilmez. Yakınlık kanıtı BLE + zaman + nokta denetiminden gelir.

Not: Top Hat, iClicker, Qwickly gibi rakipler geolocation'a ciddi ağırlık veriyor — bu, bilinen bir zafiyettir.

S10 — Cihaz saatini değiştirme 🟢

Saldırı: Öğrenci telefon saatini geri alarak geçmiş bir oturuma kayıt üretmeye çalışır.

Karşı önlem: Cihaz saatine hiç güvenilmez. Tazelik, çapanın ürettiği nonce sayacından ve sunucu zaman damgasından hesaplanır. Çevrimdışı senaryoda öğretmen cihazının monoton saati (elapsedRealtimeNanos) ve oturum anahtarı referans alınır.

Kalan risk: Yok.

4. Zamanlama ve davranış saldırıları

S15 — Yoklama alıp sınıftan çıkma 🟢

Karşı önlem: Rastgele zamanlı 2-3 tur (Mod A). Öğrenci ne zaman doğrulama isteneceğini bilemez. presence_ratio eşiği ve ERKEN_AYRILDI bayrağı.

Kalan risk: Turlar arası boşluk. Mod B (BLE varlık sinyali) bunu daraltır ama BLE tek başına kanıt sayılmaz (telefon bırakılabilir — bkz. S17).

S16 — Geç gelip sadece son tura yetişme 🟢

Karşı önlem: GEÇ_KATILDI bayrağı + presence_ratio eşiği. 3 turdan 1'ine katılan öğrenci 0,33 oranıyla YOK sayılır (varsayılan eşik 0,70).

S17 — Telefonu sınıfta bırakıp çıkma 🟢

Saldırı: Öğrenci doğrulamayı yapar, telefonu sırada bırakıp gider. BLE varlık sinyali devam eder.

Karşı önlem: Bu tam olarak BLE'ye neden tek başına güvenilmediğinin sebebidir. Sonraki turlarda yüz doğrulaması istenir — telefon sırada ama öğrenci yok → doğrulama başarısız → SADECE_BLE bayrağı → sayılmaz.

Kalan risk: Yok — mimari zaten bunu varsayıyor.

S28 — Kasıtlı düşük kalite ile "belirsiz" durumunu sömürme 🟡

Saldırı: Öğrenci kasıtlı olarak kötü ışık/açı ile doğrulama yapıp sistemin "emin değilim" davranışını sömürmeye, sonra "sistem çalışmadı, beni manuel işaretleyin" demeye çalışır.

Karşı önlem: Sistem asla "belirsiz → var" demez; fail-closed. Belirsiz sonuç Y3'e (öğretmen onaylı manuel) yönlendirir ve source=manual etiketlenir. Panelde öğrenci bazında manuel oran raporlanır — sürekli manuel işaretlenen öğrenci denetim sinyalidir. Ayrıca kalite kapısı geçilmeden doğrulama denemesi bile başlatılmaz; kullanıcıya "ışığa dönün / telefonu sabit tutun" yönlendirmesi verilir.

5. Protokol ve altyapı saldırıları

S21 — API'ye doğrudan sahte istek gönderme 🔴

Saldırı: Öğrenci ağ trafiğini yakalar, uygulamayı atlayıp doğrudan API'ye "doğrulandı" isteği gönderir.

Karşı önlem:

• Her kanıt, donanım destekli, dışa aktarılamaz anahtarla imzalıdır. Anahtar Secure Enclave/StrongBox'tan çıkarılamaz → istek uygulama dışından üretilemez.
• Nonce sunucu/çapa tarafından üretilir, tahmin edilemez, tek kullanımlıktır.
• Certificate pinning + mTLS.
• Play Integrity / App Attest belirteci sunucuda doğrulanır.

Kalan risk: Düşük — anahtar donanımdan çıkarılamadığı sürece.

Test: mitmproxy ile trafiği yakalayıp yeniden oynatma ve elle istek üretme denemesi.

S23 — Uçak modunda sahte çevrimdışı kayıt üretip sonra senkronize etme 🔴

Saldırı: Öğrenci uçak moduna alır, uygulamayı manipüle ederek geçmişe dönük "doğrulandı" kayıtları üretir, sonra senkronize eder.

Karşı önlem: Çevrimdışı kanıtlar öğretmen cihazının oturum anahtarıyla üretilen nonce'a bağlıdır. Öğrenci o nonce'u ancak fiziksel olarak çapanın menzilindeyken alabilir. Uçak modunda geçerli nonce üretilemez. Ayrıca:

• Sunucu, (session_id, student_id, sweep_index) üzerinde upsert eder — çoklu kayıt üretilemez
• Kanıtlar öğretmen cihazının outbox'ından gelir, öğrencinin cihazından değil (öncelikli yol)

Kalan risk: Düşük.

S22 — Aynı öğrencinin iki kez sayılması 🟢

Karşı önlem: (sweep_id, student_id) üzerinde benzersizlik kısıtı; ikinci kanıt sessizce yok sayılır (idempotent). Aynı device_key_id iki farklı öğrenci için kullanılırsa anomalies: duplicate_device üretilir.

S27 — Hesap paylaşımı / satışı ⚫

Saldırı: Bir öğrenci hesabını başkalarına satar veya paylaşır.

Karşı önlem: Hesap tek aktif cihaza bağlıdır (S24). Şablon o cihazda ve o öğrencinin yüzüne aittir — hesabı alan kişi doğrulamayı geçemez. Hesap paylaşımı yalnızca Y2/Y5'te anlamlıdır ve orada da cihaz bağlaması sınırlar.

Kalan risk: Düşük.

6. İnsan faktörü

S20 — Öğretmenle iş birliği 🟢

Saldırı: Öğretmen, gelmeyen öğrencileri manuel olarak "var" işaretler.

Karşı önlem: Teknik olarak çözülemez ve çözülmeye çalışılmamalıdır — öğretmen sistemin yetkili aktörüdür. Yapılan:

• Her manuel işaretleme source=manual + gerekçe + audit_log kaydı
• Panelde ders/öğretmen bazında manuel oran raporu; anormal yüksek oran denetim sinyali (anomalies: high_manual_rate)
• Nokta denetimi sonuçları ile otomatik doğrulama sonuçları arasındaki tutarsızlık ölçülür

Bu, bir "yakalama" mekanizması değil, şeffaflık mekanizmasıdır. Kurumun disiplin süreci devreye girer.

S7 — Öğrencinin kendi rızasını geri çekip alternatife kaçması 🟢

Saldırı: Öğrenci Y1'i kapatıp daha zayıf olan Y2'ye geçerek telefon devri saldırısını mümkün kılar.

Karşı önlem — ADR-007 ile değişti. Öğrenci artık kaçacağı yolu kendisi seçemez: Y2'nin o derste açık olup olmadığına öğretmen karar verir (allowed_methods, oturum başına). Öğretmen yalnızca Y1'i işaretlerse, rızasını geri çeken öğrenci Y2'ye düşmez — Y3'e, yani öğretmenin elle işaretlemesine düşer.

Ama bu ürünün garantisi değil, öğretmenin seçimidir. Varsayılan yapılandırma Y1 + Y2'dir ve o yapılandırmada senaryo aynen geçerlidir. Kapanma, öğretmenin her ders için ayrı vereceği bir karara bağlıdır.

Hukuki sınır da yerinde duruyor: rızayı geri çekmek mutlak bir haktır (KVKK m.7) ve bunun bir yaptırımı olamaz. Öğretmenin Y2'yi kapatması bir yaptırım değil, dersin yönteminin belirlenmesidir — ama rızası olmayan öğrenci o derste Y3'e kalır ve bu, ölçülülük değerlendirmesinde ayrıca gerekçelendirilmesi gereken bir sonuçtur.

Yerinde kalan önlemler:

• Y2 kullanan öğrencilerin nokta denetiminde ağırlıklandırılması (öğrenci için ek adım veya gecikme yok → kısıtlama sayılmaz)
• Kurumun devam politikasında Y2 için farklı bir eşik tanımlayabilmesi (kurumun kararı, ürünün dayatması değil)

Kalan risk: ⚠️ KISMEN — öğretmenin yapılandırmasına bağlı. Y1-only oturumda kapalı, varsayılan yapılandırmada açık. Faz 8'de ölçülmesi gereken: öğretmenler gerçekte hangi yapılandırmayı seçiyor (ADR-007 §7).

7. Risk motoruna ve makbuz katmanına yönelik saldırılar

Bu üç senaryo, docs/risk-motoru.md ve plan.md §4.2 ile birlikte ortaya çıkan yeni saldırı yüzeyidir. Bir savunma katmanı eklemek, o katmana yönelik saldırıları da beraberinde getirir; bunları yazmamak dürüst olmazdı.

S29 — Risk motorunu öğrenip kaçınma (gaming the scorer) 🔴

Saldırı: Öğrenci, hangi davranışların risk sinyali ürettiğini deneme yanılmayla çözer. Skorunu yeşil bandda tutar, denetim olasılığını sıfıra indirir, sonra tek seferlik hile yapar.

Bu, risk temelli her sistemin yapısal zafiyetidir. Denetim kaynağını "şüpheli" olana yönelten her sistem, şüpheli görünmemeyi öğrenen saldırgana kör olur.

Karşı önlemler:

1. ⭐ Rastgele taban asla kaldırılmaz. rastgele_taban = max(2, ceil(0,03 × roster)) riskten tamamen bağımsızdır. Skoru sıfır olan öğrenci de her turda seçilebilir. Risk motoru rastgeleliği yükseltir, yerine geçmez (ADR-004 §3.4).
2. Kâhin (oracle) engeli. Öğrenciye bandı gösterilmez; step-up ekranı rastgele nokta denetimi ekranıyla görsel olarak aynıdır. Öğrenci hangi mekanizmanın onu seçtiğini bilemez, dolayısıyla eşikleri haritalayamaz.
3. Sayısal ağırlıklar gizlidir (mantık kamuya açıktır — risk-motoru.md §12).

Kalan risk: ⚠️ KISMEN. Tam kaçınma engellenemez ama denetim olasılığı hiçbir zaman sıfırlanamaz. Bu, kabul edilmiş ve tasarıma yazılmış bir sınırdır.

S30 — Risk kirletme / iftira 🟡

Saldırı: Öğrenci A, rakibi veya husumetlisi olan B'nin risk skorunu yükseltmek için kasten sinyal tetikler. Örneğin B'nin telefonunu bir kez ödünç alıp kendi hesabıyla giriş yapar → R1 (aynı cihaz, birden fazla öğrenci) B'nin cihazında doğar.

Bu senaryo, risk motorunun eklenmesiyle ortaya çıkan yeni bir zarar biçimidir ve genellikle gözden kaçar: sistem, bir öğrenciyi başka bir öğrenciye zarar vermek için kullanılabilir hâle gelir.

Karşı önlemler:

1. Atıf kuralı: sinyal eylemi yapana yazılır. R1'de puan, cihazı ödünç alan hesaba yazılır — cihaz sahibine değil. device_bindings hangi hesabın hangi anahtarla imza ürettiğini kesin olarak tutar.
2. Zayıf sinyaller tek başına aksiyon almaz. Tek noktadan kirletme, step-up eşiğine ulaşmaz.
3. İtiraz ve geri alma. risk_flag_contested itirazında yönetici kanıt JSON'unu görür; sinyal hatalıysa resolved_benign işaretlenir, skordan düşer ve aynı türden sinyal o öğrenci için 30 gün bastırılır.
4. Sönümleme. Tek seferlik bir olay 30-90 günde kendiliğinden sıfırlanır; kalıcı damga oluşmaz.

Kalan risk: Düşük. Ancak koordineli kirletme (birden fazla öğrencinin birlikte bir kişiyi hedef alması) tespit edilemez. Bu, teknik değil disiplin süreciyle ele alınacak bir sorundur.

S31 — Çapayı (öğretmen cihazını) ele geçirme 🔴

Saldırı: Saldırgan, öğretmenin cihazındaki oturum anahtarına erişir (cihaz çalınır, root'lanır veya öğretmen iş birliği yapar). Oturum anahtarıyla hem BLE nonce'unu hem QR nonce'unu istediği gibi üretebilir ve sınıfta olmayan öğrenciler için geçerli görünen kanıt zinciri kurabilir.

Neden ciddi: K1 (BLE) ve K2 (QR) farklı fizik kullanır ama aynı güven kökünü paylaşır — ikisi de çapanın oturum anahtarından türer. Çapa düşerse ikisi birden düşer. Bu, üçüncü kanal eklenmeden önce sistemin görülmemiş bir tek hata noktasıydı.

Karşı önlemler:

1. ⭐ K3 — sunucu challenge'ı (plan.md §4.1). Sunucu, kayıtlı öğrenci cihazına doğrudan tek kullanımlık bir challenge gönderir; bu challenge çapadan hiç geçmez. Çapa onu ne üretebilir ne de tahmin edebilir. Öğrenci imzası üç kanalı birden kapsadığı için, çapa tek başına geçerli kanıt üretemez.
2. Öğretmen cihazı da attestation'a tabidir — root'lu çapa oturum açamaz.
3. Oturum anahtarı sunucudan gelir, süreli ve derse özgüdür; oturum kapanınca geçersizdir.
4. Makbuz Merkle kökü (plan.md §4.2) — çapa, kaydı sonradan değiştirirse zincir kırılır ve tespit edilir.
5. R16 tazelik kanalı tutarsızlığı — ağ varken sürekli 2 kanalla üretilen kanıtlar risk sinyali doğurur.

Kalan risk: ⚠️ KISMEN. required_channels: 2 politikasında (varsayılan) ve öğrenci cihazlarında internet yokken, çapa ele geçirilmişse hâlâ sahte kanıt üretilebilir. Yüksek güvenlik gerektiren kurumlar required_channels: 3 seçmelidir — bedeli ağ bağımlılığıdır. Bu takas açıkça belgelenmiştir.

Test: Öğretmen cihazının oturum anahtarı bilinerek, sınıfta olmayan bir öğrenci için kanıt üretme denemesi. Beklenen: required_channels: 3 iken reddedilir; 2 iken geçer ama makbuz zinciri ve R16 üzerinden iz bırakır.

S32 — Kâğıt çizelgeye vekâleten imza 🟢

Saldırı: Öğrenci, derse gelmeyen arkadaşının satırına da imza atar. Fotoğraflanan çizelge bunu "var" olarak içeri alır.

Karşı önlem — dürüstçe: yok. Kâğıt yoklamanın yapısal zafiyetidir ve bu ürünün var olma sebebidir. Yapılanlar:

• Kayıt Y3 / paper_sheet olarak işaretlenir, Y1 ile eşit sunulmaz (ADR-006 §3.1)
• Panelde ders ve öğretmen bazında kâğıt oranı raporlanır; yüksek oran denetim sinyalidir
• Dijital kayıtla çapraz kontrol: kâğıtta imzalı ama sistemde hiç doğrulaması olmayan öğrenci işaretlenir
• Sınıf sayımı (ADR-005) ile birlikte kullanılırsa toplu tutarsızlık görünür hâle gelir

Kalan risk: ⚠️ AÇIK. Kâğıt kullanan kurumda bu saldırı mümkündür ve sistem bunu engellemez, yalnızca görünür kılar. Bu özellik hile önleme değil, geçiş ve yedek yoludur.

Test: Sentetik çizelgede bir satıra başkası tarafından imza atılır. Beklenen: sistem bunu tespit ETMEZ ve etmediğini raporda açıkça söyler; kayıt paper_sheet olarak işaretli kalır.

Özet tablo

Sayım: 21 tam engellendi · 8 kısmen · 3 açık (S19 ikizler, S1'in Y2/Y5 kolu, S32 kâğıt çizelge).

Not: S29-S31, risk motoru ve makbuz katmanının kendisine yönelik saldırılardır. Bir savunma eklemek yeni bir saldırı yüzeyi de ekler; net kazanç pozitiftir ama bedelsiz değildir.

Hiçbir yoklama sistemi %100 kırılamaz değildir. Bu sistemin iddiası, hilenin maliyetini bir imzadan koordineli teknik saldırıya çıkarmak ve her denemede yakalanma olasılığı bırakmaktır.

Bu sayfa depodaki docs/arastirma/hile-senaryolari.md dosyasından scripts/belgeleri-uret.py ile üretilir. Elle düzenlenmez; değişiklik kaynağa yapılır.