กระเป๋าอิเล็กทรอนิกส์ยืนยันตัวตน eIDAS ของเยอรมนีใช้โครงสร้างตรวจสอบความปลอดภัยอุปกรณ์ที่อิงกับบัญชี Apple·Google

 (bmi.usercontent.opencode.de)
1 คะแนน โดย GN⁺ 24 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • National EUDI Wallet ของเยอรมนีคงไว้ซึ่งความสมบูรณ์ของการยืนยันตัวตนอิเล็กทรอนิกส์ผ่านระบบ การจัดการช่องโหว่ของอุปกรณ์พกพา (MDVM)
  • MDVM ตรวจจับช่องโหว่ของ ระบบปฏิบัติการและที่เก็บกุญแจฮาร์ดแวร์ (HKS) และหากมีความเสี่ยงสูงจะ บล็อกการใช้กุญแจยืนยันตัวตน
  • บน Android ใช้ Google Play Integrity API และ KeyAttestation ส่วนบน iOS ใช้ Apple DeviceCheck·AppAttest เพื่อตรวจสอบความสมบูรณ์ของอุปกรณ์
  • ด้วยโครงสร้างนี้ เมื่อใช้งานความสามารถด้าน ตัวตนอิเล็กทรอนิกส์ จะต้องมีกระบวนการตรวจสอบที่อิงกับบัญชี Apple หรือ Google ทำงานโดยบังคับ
  • ระบบทั้งหมดถูกออกแบบมาโดยมีเป้าหมายเพื่อ ป้องกันการคัดลอก·การใช้งานกุญแจในทางที่ผิดโดยผู้โจมตี และ คงระดับการรับประกันสูงของการยืนยันตัวตน eID

แนวคิดการจัดการช่องโหว่ของอุปกรณ์พกพา (Mobile Device Vulnerability Management, MDVM)

  • MDVM คือระบบภายในสถาปัตยกรรม National EUDI Wallet ของเยอรมนีที่เฝ้าติดตามช่องโหว่ด้านความปลอดภัยของอุปกรณ์ผู้ใช้อย่างต่อเนื่อง และรักษาความสมบูรณ์ของวิธียืนยันตัวตน
  • ตรวจจับช่องโหว่ที่ทราบแล้วของ HKS (ที่เก็บกุญแจฮาร์ดแวร์) และ ระบบปฏิบัติการ (OS) และหากมีความเสี่ยงต่อการโจมตีสูงจะ บล็อกการใช้กุญแจ RWSCA/RWSCD
  • ด้วยวิธีนี้จึงคงระดับการรับประกันสูงในกระบวนการ ยืนยันตัวตนอิเล็กทรอนิกส์ (eID) และ ป้องกันการคัดลอก·การใช้งานกุญแจในทางที่ผิดโดยผู้โจมตี
  • MDVM ประกอบด้วย 4 ฟังก์ชัน ได้แก่ การตรวจสอบสถานะความปลอดภัยของอุปกรณ์และแอป, การระบุคลาสของอุปกรณ์, การตรวจสอบช่องโหว่ และการตัดสินใจการใช้งาน

แรงจูงใจ

  • Wallet Unit มอบวิธียืนยันตัวตนที่เชื่อมโยงกับข้อมูลยืนยันตัวตนหลายประเภท (เช่น PID) ผ่าน คู่กุญแจสาธารณะ/กุญแจส่วนตัว
  • เมื่อออก PID นั้น WB (Wallet Backend) จะตรวจสอบต่อ PP (Provider Party) ผ่าน OpenID4VCI Key Attestation ว่ากุญแจดังกล่าวถูกควบคุมโดยวิธียืนยันตัวตนที่มีความต้านทานต่อการโจมตีในระดับที่กำหนด
  • ตาม ISO/IEC 18045 และ ข้อบังคับ EU 2015/1502 การยืนยันตัวตนอิเล็กทรอนิกส์ในระดับการรับประกันสูงต้องใช้วิธียืนยันตัวตนที่แข็งแกร่ง
  • วิธียืนยันตัวตนให้การรับประกัน 2 ประการ
    1. ป้องกันการคัดลอกและการแก้ไขที่เก็บกุญแจ
    2. ป้องกันการโจมตีกลไกยืนยันตัวตนของผู้ใช้
  • การรับประกันข้อแรกสามารถทำได้ด้วย RWSCD ที่อิง HSM และบรรลุได้โดยไม่ขึ้นกับอุปกรณ์ของผู้ใช้
  • การรับประกันข้อที่สองขึ้นกับ ความปลอดภัยของอุปกรณ์ผู้ใช้ และประกอบด้วย องค์ประกอบความเป็นเจ้าของ (อิง HKS) และ องค์ประกอบความรู้ (เช่น รหัสผ่าน)
  • ในทางปฏิบัติไม่สามารถวิเคราะห์และรับรองช่องโหว่ล่วงหน้าของ HKS หรือ OS บนอุปกรณ์พกพาได้ และที่ผ่านมาเคยมีการรายงานช่องโหว่จำนวนมาก
  • ดังนั้นจึงต้องลดความเป็นไปได้ในการโจมตีผ่าน ระบบเฝ้าติดตามช่องโหว่ระหว่างการใช้งาน (MDVM) และ บล็อกการใช้กุญแจ RWSCA/RWSCD บนอุปกรณ์ที่มีความปลอดภัยไม่เพียงพอ

ฟังก์ชันหลักของ MDVM

ฟังก์ชัน คำอธิบาย
การตรวจสอบสถานะความปลอดภัยของอุปกรณ์/แอป ตรวจสอบความสมบูรณ์และความเป็นของแท้ของอุปกรณ์และแอป Wallet โดยใช้ความสามารถด้านความปลอดภัยของแพลตฟอร์มและ RASP (Runtime Application Self-Protection)
การระบุคลาสของอุปกรณ์ ระบุรุ่นอุปกรณ์, เวอร์ชัน OS และระดับแพตช์, รวมถึงข้อมูล HKS ด้วยวิธีที่ตรวจสอบได้
การตรวจสอบช่องโหว่ตามคลาสอุปกรณ์ ตรวจสอบข้อมูลช่องโหว่ล่าสุดของ OS และ HKS
การตัดสินใจการใช้งานอุปกรณ์/แอป อิงจากสถานะความปลอดภัยและข้อมูลช่องโหว่ โดยจะ บล็อกการตรวจสอบ OpenID4VCI Key Attestation และ การใช้กุญแจ RWSCD บนอุปกรณ์ที่มีความปลอดภัยไม่เพียงพอ

สัญญาณที่รวบรวม

  • สัญญาณที่รวบรวมถูกใช้เพื่อ การตอบสนองต่อภัยคุกคาม, การระบุคลาสของอุปกรณ์, และ การตรวจสอบความสมเหตุสมผล (plausibility check)

  • แหล่งสัญญาณหลัก: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • ภาพรวม

    แหล่งสัญญาณ ภัยคุกคามที่รับมือ ซินเนอร์จี หมายเหตุ
    KeyAttestation การรูท, การปลดล็อกบูตโหลดเดอร์, Custom ROM, การแก้ไขแอป, การโคลน, อีมูเลชัน, การโจมตีแบบรีเพลย์ ฯลฯ LPADB, RASP ใช้เป็นอินพุตของ DCVDB
    PlayIntegrity การแก้ไขแอป, รีเพลย์, การรูท, Custom ROM, การตัดสิน MDVM ที่อิง Google backend, เครื่องมือขโมยข้อมูลรับรอง, การโจมตีแบบโอเวอร์เลย์ ฯลฯ KeyAttestation, RASP จำเป็นต้องตรวจสอบสถานะบูตโหลดเดอร์
    iOS DeviceCheck รีเพลย์, การแก้ไขใบรับรอง, การโจมตีผ่านพร็อกซี, การแก้ไขแอป RASP ขาดการรับประกันความสมบูรณ์ของอุปกรณ์ที่เพียงพอ
    LPADB การซ่อนการรูทด้วยการใช้กุญแจ KeyAttestation ที่รั่วสู่สาธารณะ KeyAttestation -
    DCVDB การตรวจพบอุปกรณ์ไม่ปลอดภัยจากช่องโหว่ที่ทราบแล้ว KeyAttestation, RASP ความแม่นยำของการระบุคลาสอุปกรณ์สำคัญ
    RASP ตรวจจับการ hook แอป, การดีบัก, การรูท, อีมูเลชัน - เฝ้าติดตามความสมบูรณ์อย่างต่อเนื่องระหว่างรันไทม์

สัญญาณ Android KeyAttestation

  • ระบุรุ่นอุปกรณ์, เวอร์ชัน OS, ระดับแพตช์, สถานะบูตโหลดเดอร์ ฯลฯ ผ่าน ข้อมูลการตรวจสอบฮาร์ดแวร์ที่อิง HKS
  • รายการสัญญาณหลัก
    • SecurityLevel: ระบุประเภท HKS (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: ระบุรุ่นอุปกรณ์
    • osVersion / osPatchLevel: เวอร์ชัน OS และระดับแพตช์ความปลอดภัย
    • RootOfTrust: สถานะบูตโหลดเดอร์และ Verified Boot
    • AttestationApplicationId: ชื่อแพ็กเกจแอป, เวอร์ชัน, แฮชใบรับรองลายเซ็น
  • รายการเพิกถอนใบรับรอง Key-Attestation ของ Google อัปเดตช้า ทำให้ กุญแจที่รั่วสู่สาธารณะ ยังสามารถถูกใช้งานได้
  • ในบางอุปกรณ์อาจไม่มีบางฟิลด์ระบุตัวตน จึงต้องประเมินทั้งสามฟิลด์ร่วมกัน

สัญญาณ Android PlayIntegrity Verdict

  • ตรวจสอบความสมบูรณ์ของแอปและอุปกรณ์ผ่าน Google Play Integrity API
  • รายการสัญญาณหลัก
    • appRecognitionVerdict: แอปเป็นของแท้หรือไม่
    • deviceRecognitionVerdict: ระดับความน่าเชื่อถือของอุปกรณ์ (เช่น MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: ติดตั้งผ่าน PlayStore หรือไม่
    • playProtectVerdict: การประเมินความเสี่ยงจาก Play Protect
  • MEETS_STRONG_INTEGRITY กำหนดให้มีการติดตั้งแพตช์ความปลอดภัยภายใน 12 เดือนล่าสุด
  • เพื่อให้สัญญาณเชื่อถือได้ จำเป็นต้องมี การตรวจสอบลายเซ็นและการถอดรหัส
  • วิธีประเมินภายในของ Google backend ไม่ถูกเปิดเผย

Android RASP

  • ยังไม่ได้กำหนดโซลูชันที่ชัดเจน และอยู่ในขั้นกำหนดความต้องการของฟังก์ชัน
  • ความสามารถในการตรวจจับ
    • App Hooking/Debugging: ตรวจจับการดัดแปลงแบบไดนามิก (เช่น Frida, Xposed)
    • App Repackaging/Tampering: ตรวจจับการแก้ไขแอปและการเซ็นชื่อใหม่
    • UD Rooting/Emulation: ตรวจจับการรูท, การจำลองเสมือน, สภาพแวดล้อมอัตโนมัติ
  • RASP ให้การเฝ้าติดตามความสมบูรณ์ระหว่างรันไทม์ และคงไว้ซึ่ง บล็อกลิสต์แยกต่างหากจากรายการเพิกถอนของ Google เพื่อป้องกันการโจมตีที่อิงกับกุญแจรั่ว

iOS DCDeviceCheck.AppAttest Attestation

  • โครงสร้างการยืนยันแอปผ่าน Secure Enclave และ เซิร์ฟเวอร์ของ Apple
  • สัญญาณหลัก
    • attestationObject: พิสูจน์ว่ากุญแจ App Attest ถูกสร้างใน Secure Enclave
    • credentialId: ตัวระบุกุญแจ App Attest
    • RP ID: App ID prefix + Bundle ID ของแอป
  • ตัวชี้วัดความเสี่ยงของ Apple (receipt metric) สามารถใช้ตรวจจับการโจมตีผ่านพร็อกซีได้ แต่ไม่มีเกณฑ์ที่ชัดเจน และมี ความเสี่ยงการเปิดเผยข้อมูลส่วนบุคคลจากการสื่อสารกับเซิร์ฟเวอร์ของ Apple
  • บน iOS ไม่สามารถให้ข้อมูลฮาร์ดแวร์เกี่ยวกับรุ่นอุปกรณ์, เวอร์ชัน OS/ระดับแพตช์ ได้ และตรวจสอบได้เพียงผ่านการสอบถาม OS เท่านั้น

iOS DCDeviceCheck.AppAttest Assertions

  • โครงสร้างการตรวจสอบที่อิงลายเซ็นซึ่งสร้างด้วย กุญแจ App Attest
  • สัญญาณหลัก
    • assertionObject: มีลายเซ็นสำหรับ challenge
    • keyId: ตัวระบุกุญแจ App Attest
    • counter: จำนวนครั้งของการลงลายเซ็น ซึ่งต้องเพิ่มขึ้นแบบโมโนโทนิก
  • ค่าตัวนับที่เพิ่มขึ้นอย่างรวดเร็ว อาจบ่งชี้ถึงการโจมตีผ่านพร็อกซี และ ค่าที่ลดลง อาจบ่งชี้ถึง การโจมตีแบบรีเพลย์

iOS RASP

  • ต้องการความสามารถในการตรวจจับคล้ายกับ Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • App Sandbox, Code Signing, System Integrity Protection ของ Apple ให้การป้องกันเฉพาะตอนติดตั้งเท่านั้น และ ไม่มีความสามารถตรวจจับการรูท·การ hook·การดัดแปลงระหว่างรันไทม์
  • RASP เข้ามาเสริมในส่วนนี้ด้วยการเฝ้าติดตามความสมบูรณ์ระหว่างการทำงาน
  • ตามเอกสารของ Apple App Attest ระบุว่า “แอปที่ถูกแก้ไขซึ่งรันบนอุปกรณ์ปกติไม่สามารถสร้าง assertion ที่ถูกต้องได้”

บทสรุป

  • MDVM ประเมินสถานะความปลอดภัยของอุปกรณ์แบบเรียลไทม์ และ บล็อกการใช้กุญแจยืนยันตัวตนในสภาพแวดล้อมที่มีโอกาสถูกโจมตีสูง เพื่อ คงความน่าเชื่อถือของระบบยืนยันตัวตนอิเล็กทรอนิกส์
  • ทั้ง Android และ iOS ประกอบเป็น ระบบตรวจสอบความสมบูรณ์ของอุปกรณ์ โดยผสาน ความสามารถด้านความปลอดภัยของแพลตฟอร์ม กับ การป้องกันเชิงพลวัตที่อิง RASP
  • มี การพึ่งพาระบบตรวจสอบฝั่ง backend ของ Google และ Apple และ วิธีประเมินภายในที่ไม่เปิดเผย ยังคงเป็นปัจจัยความไม่แน่นอนที่อาจมีอยู่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 24 일 전
ความเห็นจาก Hacker News

  • สเปก eIDAS 2.0 ไม่ได้กำหนดให้ต้องใช้ฮาร์ดแวร์เฉพาะ
    มันเป็นเพียงโครงสร้างสำหรับเก็บ ข้อมูลรับรองที่ตรวจสอบได้ และใบรับรองที่ลงลายเซ็นด้วยคริปโตกราฟี
    ดูเหมือนว่าทีมที่พัฒนาฝั่งเยอรมนีกำลัง ขี้เกียจ จนพยายามหลีกเลี่ยงข้อกำหนดที่ว่า “ต้องมีเมกานิซึมที่ให้ผู้ใช้ตรวจสอบความแท้จริงของ Wallet Unit ได้”
    ดูเอกสารที่เกี่ยวข้องได้ที่ EUDI Architecture and Reference Framework

    • ถ้าดูจาก implementation อ้างอิง จะเห็นว่าผู้ดูแลโปรเจ็กต์ไม่ต้องการตัด การพึ่งพา Google ออก
      เหตุผลไม่ชัดเจน แต่ถ้าสิ่งนี้ยังคงอยู่โดยไม่มีเหตุผล ก็แปลว่าสุดท้ายมันย่อมมีเหตุผลของมัน
      ดู GitHub repository
    • ในหัวข้อ 5.4 ส่วน Attestation Rulebooks และ Attestation Schemes ได้ระบุกฎที่เกี่ยวข้องไว้อย่างชัดเจน

  • ในฐานะผู้พัฒนาฝั่งเยอรมนี ตามกฎบังคับใช้ของ eIDAS เราจำเป็นต้องใช้ เมกานิซึม attestation
    ซึ่งมันทำงานไม่ได้หากไม่ได้รับการสนับสนุนจากระบบปฏิบัติการ
    เรารู้อยู่ว่าการจำกัดไว้แค่ Google/Android ในตอนนี้ไม่ใช่ทางออกที่ดีที่สุด และก็มีแผนจะรองรับ OS อื่นอย่าง GrapheneOS ด้วย
    ตอนนี้เป็นแค่เรื่องของ ลำดับความสำคัญ ไม่ใช่ว่าเราไม่ตระหนักถึงปัญหา

    • การต้องพึ่งพาผลิตภัณฑ์ของบริษัทอเมริกันสองราย ไม่ใช่แค่ “ไม่ดี” แต่เป็น ปัญหาร้ายแรง
      มีกรณีบัญชีถูกล็อกจำนวนมาก และการมีความพึ่งพาแบบนี้ สู้ไม่มีเสียยังดีกว่า
    • มันยังมี องค์ประกอบที่ผิดกฎหมาย ทั้งในแง่การเข้าถึงและการขัดกับเจตนารมณ์ของ eIDAS
      ท้ายที่สุดประชาชนทุกคนจะถูกบังคับให้อยู่ภายใต้ข้อกำหนดของ Google และ Apple และถ้าบัญชีถูกระงับก็จะเข้าใช้บริการ eID ไม่ได้
      ในเมื่อมีทางเลือกทางเทคนิคอยู่แล้ว การหาวิธีแก้แบบนั้นจึงเป็น ความรับผิดชอบ ของคุณ
    • ในฐานะพลเมืองเยอรมัน ฉันอยากถามว่า ถ้ารู้อยู่แล้วว่ามันจะใช้ไม่ได้กับประชาชนทุกคน ทำไมยังเดินหน้าต่อ?
      ฉันย้ายจาก Android แบบ AOSP ที่ไม่มี Google Play ไปใช้ Ubuntu Touch แล้ว และในอนาคตมีแผนจะย้ายไป postmarketOS
    • การสูญเสียการเข้าถึงบัญชี Google เป็นเรื่องที่ง่ายเกินไป และแทบกู้คืนไม่ได้
      เมื่อคำนึงถึงสถานการณ์แบบนี้รวมถึง ความเสี่ยงทางภูมิรัฐศาสตร์ การพึ่งพาบริษัทใดบริษัทหนึ่งจึงไม่อาจให้เหตุผลรองรับได้
      ประสบการณ์นักพัฒนาก็สอนว่า “วิธีชั่วคราวคือวิธีแก้ที่ถาวรที่สุด”
    • ไม่เข้าใจว่าทำไมต้องเปลี่ยนไปใช้โมเดล Wallet ทั้งที่ปัญหานี้ถูกแก้ไปแล้วด้วย Mobile-ID ของ eIDAS 1 (แบบ SIM) หรือ Smart-ID (จัดการคีย์ฝั่งเซิร์ฟเวอร์)
      ไม่มีเหตุผลที่ต้องไปพึ่งพาแบ็กเอนด์ของบริษัทอเมริกันสองรายนั้น

  • ควร ยกเลิก attestation ไปเลย
    แอปไม่ควรรู้ว่ากำลังรันอยู่บนอุปกรณ์อะไร
    ผู้ใช้ปกป้องอุปกรณ์ของตัวเองได้ และนักพัฒนาก็แค่เสนอคำแนะนำก็เพียงพอ
    มันควรรันได้ในทุกสภาพแวดล้อม ไม่ว่าจะเป็น GrapheneOS, เครื่องรูท, อีมูเลเตอร์ หรือเลเยอร์ความเข้ากันได้ของ Linux

    • ถูกต้อง นี่คืออุปกรณ์ของฉัน ฉันควรใช้มันได้ตามต้องการ
      การที่แอปไปตรวจอัตโนมัติว่าได้รับ “การรับรอง” จากบิ๊กเทคอเมริกันหรือไม่ เป็นเรื่องไม่จำเป็น
    • แนวคิดเรื่อง ความน่าเชื่อถือของอุปกรณ์ เองก็เป็นภาพลวง
      ถ้าดูประวัติของคอนโซลและโทรศัพท์ที่ถูก root จะเห็นว่าไม่มีความปลอดภัยใดสมบูรณ์แบบ
      ทางที่ดีกว่าคือทำให้การผูกตัวตนเข้ากับอุปกรณ์เป็น ตัวเลือก สำหรับผู้ใช้ที่ต้องการ
    • แน่นอนว่าคุณมีอิสระจะ root หรือดัดแปลง แต่ก็ต้องรับผลที่ตามมาด้วย
      หากแอปไม่สามารถตรวจสอบความสมบูรณ์ของตัวเองได้ ฟังก์ชันบางอย่างก็ เป็นไปไม่ได้ในเชิงความปลอดภัย
      เหมือนกับบัตรประชาชนจริงที่มีข้อจำกัดเรื่องรูปแบบหรือขนาด การมีข้อจำกัดบางอย่างก็จำเป็น
    • บาปกำเนิด ของคอมพิวเตอร์ยุคใหม่คือ ‘องค์ประกอบด้านความปลอดภัย’ ถูกออกแบบมาเพื่อผู้ผลิตมากกว่าผู้ใช้
      การที่ยุค NGSCB ไม่มีการห้ามองค์ประกอบแบบนี้ทางกฎหมาย คือจุดเริ่มต้นของปัญหา

  • ถ้าสูญเสียบัญชี Google/Apple ไปจะเกิดอะไรขึ้น?
    ถ้าถูกคว่ำบาตรแบบผู้พิพากษาศาลอาญาระหว่างประเทศ ก็จะเข้าใช้ eIDAS ไม่ได้
    การที่สังคมยุโรปยังคงรักษาโครงสร้างที่พึ่งพาบริษัทอเมริกันอยู่ เป็น ความจริงที่ย้อนแย้ง

    • ต่อให้ไม่ใช่คนดัง ก็อาจถูกกันออกจากสังคมได้จากการระงับบัญชีอัตโนมัติ
      การที่บริษัทต่างชาติสองแห่งมี อำนาจในการสอดส่องและควบคุม เป็นเรื่องอันตราย
    • “ถ้าเมืองหลวงของยุโรปอยู่ที่วอชิงตัน” เรื่องแบบนี้ก็คงเป็นเรื่องปกติ
    • งั้นก็คงขึ้น Waymo ไม่ได้เหมือนกัน

  • น่าตกใจที่มี การคัดค้านจากสาธารณะน้อยมาก ต่อแนวนโยบายแบบนี้
    ในฐานะพ่อแม่ ฉันเข้าใจว่าจำเป็นต้องควบคุมการใช้อินเทอร์เน็ตของลูก ๆ
    แต่ท้ายที่สุดรัฐกำลังเข้ามาทำแทนสิ่งที่พ่อแม่ควรทำ และเราก็กำลังสูญเสีย เสรีภาพและความเป็นส่วนตัว

    • คนส่วนใหญ่เข้าใจผลกระทบที่สิ่งนี้มีต่อชีวิตตัวเองแค่ในระดับ นามธรรม
      ถ้าไม่ใช่ภัยคุกคามที่จับต้องได้แบบ “รัฐบาลอ่านข้อความ WhatsApp ของฉัน” ก็จะไม่ค่อยตอบสนอง
    • เยอรมนีกำลังถูกดึงความสนใจไปกับประเด็น ไร้สาระสิ้นเปลือง อย่างการถกเถียงเรื่องจำกัดความเร็ว
      ฝ่ายการเมืองก็อาศัยความสับสนนี้เพื่อกลบปัญหาสาระสำคัญ
    • ในทางกลับกัน พ่อแม่จำนวนมากกลับสนับสนุนการจำกัดการเข้าถึงออนไลน์
      พวกเขาอยากให้ลูกได้รับการปกป้องจาก การช่วงชิงความสนใจ โดยบริษัทยักษ์ใหญ่
      เช่นเดียวกับที่โลกจริงมีข้อจำกัดเรื่องอายุ โลกออนไลน์ก็ไม่ควรเป็นข้อยกเว้น
    • ผู้คนติดอยู่ใน ฟองกรองข้อมูล ของตัวเองจนไม่ได้ยินเรื่องแบบนี้เลย
      ถ้าคิดถึงอนาคตของประชาธิปไตยแล้ว ก็น่ากังวลมาก
    • แท้จริงแล้ว EU ทำงานแทบจะเป็น แพลตฟอร์มสำหรับการวิ่งเต้น
      ภาคประชาชนก็วิ่งเต้นได้ แต่ต้องใช้ต้นทุนและการประสานงาน ทำให้บรรษัทใหญ่เป็นฝ่ายได้เปรียบ
      ช่วงไม่นานมานี้โครงสร้างพื้นฐานดิจิทัลของ EU ก็เพิ่งถูกกลุ่มแฮ็กเกอร์เจาะ
      บทความที่เกี่ยวข้อง

  • การกำหนดให้ต้องใช้ฮาร์ดแวร์หรือซอฟต์แวร์เฉพาะเป็นเรื่อง ไร้เหตุผล
    พลเมืองทุกคนควรมีสิทธิใช้คอมพิวเตอร์ที่ตนต้องการ
    การยืนยันตัวตนใช้แค่รหัสผ่านหรือคู่กุญแจก็เพียงพอ และถ้าต้องการก็เพิ่ม TOTP หรือ security key ได้
    ดูเหมือนพวกเขาจะลืมไปว่ายังมีคอมพิวเตอร์ประเภทอื่นนอกจากสมาร์ตโฟน

    • EU บอกว่าจะสร้างระบบชำระเงินที่เป็นอิสระจาก VISA และ MasterCard แต่สุดท้ายก็ยัง พึ่งพา app store
      ถ้าไม่มีบัญชี Apple หรือ Google ก็จ่ายเงินด้วยดิจิทัลยูโรไม่ได้อยู่ดี
      น่าประหลาดใจที่นักการเมืองกับธนาคารมองอนาคตไปไม่ถึงสองสามก้าว
    • นโยบายของ EU กำลังมุ่งไปในทิศทางที่ไม่ใช่ “ให้ผู้ใช้ประเมินความเสี่ยงด้วยตนเอง”
      แต่เป็นให้ผู้ให้บริการต้องปกป้องผู้ใช้
      ผลลัพธ์คือการ จำกัดแพลตฟอร์มที่รองรับ กลายเป็นสิ่งหลีกเลี่ยงไม่ได้
    • การบอกว่า “ควรรันได้บนคอมพิวเตอร์ทุกเครื่อง” ก็ไม่สมจริงนัก
      มันไม่ได้หมายความว่าตามกฎหมายต้องรันบน Apple II ได้ด้วยเสียหน่อย

  • ผู้ที่ถูกคว่ำบาตรหรือคนบางกลุ่มอาจเข้า Play Store ไม่ได้
    ดังนั้นตัวแอป eIDAS เองก็อาจติดตั้งไม่ได้

    • ถ้าต้องมีบัญชี ก็ใช่แหละ
      ดูจากกรณีล่าสุดที่มีการ ลบบัญชีฝ่ายตรงข้ามทางการเมือง สำหรับเจ้าหน้าที่บางฝ่าย นี่อาจยิ่งเป็นเรื่องน่ายินดีด้วยซ้ำ
    • แต่แก่นสำคัญคือการปกป้อง private key
      จึงต้องมี อุปกรณ์ความปลอดภัย อย่างสมาร์ตการ์ด และสภาพแวดล้อมที่เปิดจนเกินไปก็เสี่ยงเกินไป
      ฉันเข้าใจนะว่าอยากใช้ “Android ทางเลือก” แต่คุณก็ต้องรู้ว่านั่นคือ สภาพแวดล้อมที่ไม่ปลอดภัย

  • สงสัยว่า EU จะ เผางบประมาณ ไปกับระบบแบบนี้มากแค่ไหน
    ไม่รู้จริง ๆ ว่าใครต้องการมัน

  • มีเพียง Self Sovereign Identity (SSI) เท่านั้นที่เป็นทางออกที่แท้จริง
    ตัวตนของบุคคลไม่ควรถูกผูกติดกับหน่วยงานหรือบริษัทใด
    ตัวตนก็ควรเป็นเพียง ‘ตัวฉันเอง’
    สิ่งที่จำเป็นไม่ใช่ Google ID หรือ Apple ID แต่คือ อัตลักษณ์ที่มีอธิปไตยของตนเอง

    • แต่การบอกว่า “ฉันก็แค่ฉัน” ไม่ใช่การยืนยันตัวตนในโลกจริง
      คุณไม่สามารถพูดแบบนั้นแทนการแสดงบัตรที่หน้าบาร์ได้
      ภายใต้สัญญาทางสังคม เราจำเป็นต้องมี การยืนยันตัวตนเชิงหน้าที่
    • EU ได้สร้าง ESSIF (European Self-Sovereign Identity Framework) มาตั้งแต่ปี 2019 แล้ว
      โครงสร้างพื้นฐานมีอยู่มา 7 ปีแล้ว จะโทษว่ารัฐไร้ความสามารถอย่างเดียวก็คงไม่ได้

  • ดูเหมือนถึงเวลาของ “เหตุไฟไหม้อาคารไรชส์ทาคฉบับดิจิทัล” แล้ว
    อยากถามว่าเยอรมนีจะเลิก ทำประวัติศาสตร์ซ้ำรอย ได้เมื่อไร