Face Transit Pass Güvenliği: Saldırılar, Hata Senaryoları ve Manuel Fallback

Face Transit Pass, yolcunun aktarma sürecinde belge göstermeden ilerlemesini sağlayabilir. Ancak yüz eşleşmesinin başarılı olması, bütün seyahat kararının güvenli olduğu anlamına gelmez. Kamera akışı, dijital kimlik, uçuş yetkisi, transit kuralları ve token yaşam döngüsü ayrı saldırı yüzeyleridir.

Bu yazıda Face Transit Pass ifadesi, doğrulanmış dijital kimlik ve journey yetkisinden türetilen kısa ömürlü mimari bir nesneyi ifade eder; resmi bir standart adı değildir.

Tehdit modeli

• Basılı portre veya telefon ekranıyla presentation attack
• Kamera akışına deepfake veya önceden kaydedilmiş video enjekte edilmesi
• Morphing yapılmış pasaport portresi
• Çalınmış telefon, wallet veya journey credential
• Eski transit token’ın yeniden kullanılması
• Token’ın başka terminal veya kapıda kullanılması
• Havayolu değişiminde yanlış journey binding
• Yanlış yüz eşleşmesi, ikizler veya ciddi görünüm değişikliği
• Kamera, ağ, issuer registry veya revocation servisinin kesilmesi

Katmanlı karar modeli

DOCUMENT / DTC TRUST       PASS
JOURNEY AUTHORIZATION      PASS
TOKEN SIGNATURE            PASS
TOKEN FRESHNESS            PASS
LIVE CAPTURE                PASS
PRESENTATION ATTACK         PASS
FACE MATCH                  REVIEW
TRANSIT ELIGIBILITY         PASS

FINAL                       MANUAL_REVIEW

Tek bir “biometric passed” alanı güvenlik analizi için yetersizdir. Her kontrolün sonucu, veri kaynağı ve politika sürümü ayrı tutulmalıdır.

Politika motoru örneği

from enum import Enum

class State(str, Enum):
    PASS = "PASS"
    REVIEW = "REVIEW"
    FAIL = "FAIL"
    UNAVAILABLE = "UNAVAILABLE"

def decide(checks):
    hard_fail = {
        "credential_signature",
        "journey_authorization",
        "token_freshness",
        "transit_eligibility"
    }

    failed = [name for name, state in checks.items()
              if state == State.FAIL]
    unavailable = [name for name, state in checks.items()
                   if state == State.UNAVAILABLE]

    if any(name in hard_fail for name in failed):
        return "DENY", failed
    if failed or unavailable or State.REVIEW in checks.values():
        return "MANUAL_REVIEW", failed + unavailable
    return "PASS", []

Replay saldırısını önlemek

Transit token kısa ömürlü olmalı, benzersiz jti taşımalı ve touchpoint/audience ile sınırlandırılmalıdır. Kontrol noktası imzayı doğrulasa bile token’ın daha önce tüketilip tüketilmediğini veya iptal durumunu kontrol etmelidir.

def verify_token(claims, checkpoint, replay_store, now):
    if now >= claims["exp"]:
        return "FAIL", "TOKEN_EXPIRED"
    if checkpoint not in claims["aud"]:
        return "FAIL", "WRONG_TOUCHPOINT"
    if replay_store.was_used(claims["jti"], checkpoint):
        return "FAIL", "REPLAY_DETECTED"

    replay_store.mark_used(claims["jti"], checkpoint, claims["exp"])
    return "PASS", None

Presentation attack ve injection ayrımı

Presentation attack, kameranın önüne basılı fotoğraf, ekran veya maske getirilmesidir. Injection attack ise kamera veya uygulama hattına sahte dijital görüntü verilmesidir. Liveness modeli bir ekran saldırısını yakalasa bile, güvenilmeyen kamera sürücüsüne yapılan injection saldırısını göremeyebilir.

Capture zincirinde cihaz kimliği, secure boot/attestation, imzalı frame metadata, zaman bilgisi ve replay kontrolü değerlendirilebilir. Bunlar da tek başına yeterli değildir; risk tabanlı ve katmanlı kullanılmalıdır.

Morphing riski

Geçerli bir pasaportun çip portresi morph ise Passive Authentication başarılı olabilir; çünkü veri düzenleyen makam tarafından gerçekten imzalanmıştır. Sınır noktasında D-MAD, çipteki referans portre ile güvenilir canlı capture arasındaki morph göstergelerini incelemelidir. Bu sonuç yüz eşleştirme skorundan ayrı tutulmalıdır.

Fallback matrisi

| Arıza / Durum              | Güvenli fallback                 |
|----------------------------|----------------------------------|
| Kamera kullanılamıyor      | Fiziksel belge + görevli kontrolü|
| Face match sınırda         | İkinci capture + manuel inceleme |
| Liveness başarısız         | Kontrollü kabin / görevli        |
| Token registry erişilemiyor| Offline policy veya manuel yol   |
| Journey verisi tutarsız    | Airline transfer desk            |
| Yolcu biyometri istemiyor  | Belge/boarding pass ile işlem    |

Offline policy yalnız önceden tanımlı düşük riskli işlemler için kullanılmalıdır. İmza veya journey yetkisi doğrulanamıyorsa sistem “hız için kabul” kararı vermemelidir.

Yeniden deneme güvenliği

Sınırsız biyometrik yeniden deneme, eşik keşfi ve kuyruk manipülasyonuna yol açabilir. Deneme sayısı, cihaz ve journey bazında sınırlandırılmalı; fakat erişilebilirlik ihtiyacı olan yolcu cezalandırılmamalıdır.

def retry_policy(attempts, quality, accessibility_override=False):
    if accessibility_override:
        return "ASSISTED_CAPTURE"
    if quality == "POOR" and attempts < 2:
        return "RECAPTURE"
    if attempts >= 2:
        return "MANUAL_REVIEW"
    return "RETRY"

Olay kaydı

{
  "event": "TRANSIT_TOUCHPOINT_DECISION",
  "journeyRef": "rotating-pseudonym",
  "checkpoint": "CONNECTION_GATE",
  "checks": {
    "credentialSignature": "PASS",
    "liveness": "PASS",
    "faceMatch": "REVIEW",
    "tokenFreshness": "PASS"
  },
  "decision": "MANUAL_REVIEW",
  "reasonCodes": ["FACE_SCORE_BORDERLINE"],
  "rawBiometricLogged": false
}

Sonuç

Face Transit Pass güvenliği, yalnızca iyi bir yüz tanıma modeli seçmek değildir. Credential güveni, canlı capture, injection savunması, journey doğrulaması, token replay koruması ve insan kontrollü fallback birlikte tasarlanmalıdır. Sistem belirsizliği gizlemek yerine açıkça REVIEW durumuna taşımalıdır.

Referanslar

• IATA One ID
• NISTIR 8584 — Morph Detection in Operations
• IATA Contactless Travel Solutions