By: lew 
on 17 April 2017 - 11:57
Tags:
Topics:
NIST เปิดตัวมาตรการการเข้ารหัสแบบรักษาฟอร์แมตข้อมูล (Format-Preserving Encryption - FPE) มาตั้งแต่ปีที่แล้ว ตอนนี้ทาง HPE ประกาศว่าโซลูชั่น SecureData ของบริษัทเป็นโซลูชั่นแรกที่ได้รับการรับรอง (validated) ตามมาตรฐานนี้
HPE SecureData with Hyper FPE ใช้กระบวนวิธีเข้ารหัสแบบ AES-FF1 เป็นหนึ่งในสามกระบวนวิธีที่มาตรฐานของ NIST รับรองให้ใช้งาน
ทาง HPE ระบุว่าบริษัทได้รับการรับรองจาก NIST ตั้งแต่วันที่ 13 เมษายนที่ผ่านมา ผมเองตรวจสอบรายชื่อในเว็บของ NIST ยังไม่พบ แต่หากไม่มีอะไรผิดพลาดก็น่าจะมีรายการสินค้าที่ได้รับการรับรองเร็วๆ นี้
การเข้ารหัสแบบ FPE ทำให้หน่วยงานสามารถส่งต่อข้อมูลโดยไม่เปิดเผยตัวตน (de-identification) ได้ ตัวข้อมูลที่ปิดบังตัวตนยังคงมีฟอร์แมตคงเดิม เช่น ชื่อนามสกุลก็ยังคงเป็นตัวอักษรปกติ ขณะที่หมายเลขบัตรเครดิตก็ยังเป็นเลข 16 หลักเช่นเดิม แม้แต่วันเดือนปีก็สามารถเข้ารหัสได้เช่นกัน ประโยชน์การใช้งานเช่นการส่งข้อมูลออกไปประมวลผลภายนอกแต่ต้องการปิดบังตัวตนของเจ้าของข้อมูล เช่น การประมวลพฤติกรรมการซื้อสินค้าโดยไม่เปิดเผยชื่อลูกค้า แทนที่จะใช้การปิดข้อมูลบางส่วน เช่นส่งหมายเลขบัตรเครดิตบางหลักเช่นทุกวันนี้ ก็ให้เข้ารหัสข้อมูลทั้งชุดได้เลย
ที่มา - HPE Security
Get latest news from Blognone
Follow @twitterapi
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
น่าสนใจ ว่าการทำ FPE กับเลขบัตรเครดิตโดยให้ออกมามีจำนวนหลักเท่าเดิม แล้วผลออกมามันไม่ไปซ้ำกับเลขจริงๆของคนอื่นหรือไม่? (bin) และผลที่ได้ unique หรือไม่?
เพราะขนาดการ masking ตามหลักที่ไม่โชว์ full PAN ทุกวันนี้ ที่โชว์หน้าหกหลัก หลังสี่หลัก ยังมีโอกาสเจอชุดเลขซ้ำ(ไม่unique) ได้ง่ายๆเลยกับปริมาณบัตรที่มากพอ และทำให้เกิดการนับข้อมูลซ้ำ เพราะแยกไม่ได้ว่าเป็นของใครกันแน่
ถ้าผมเข้าใจถูกต้องคือจะออกมาไม่ซ้ำแน่นอนครับ เพราะมันเป็น encryption (การเข้ารหัส) ซึ่งแปลว่าถ้ารู้ key ที่ใช้เข้ารหัส จะต้องถอดเลขบัตรที่ผ่าน FPE กลับมาเป็นเลขเดิมได้ครับ
ที่กลัวจะซ้ำคือเข้ารหัสแล้วเลขออกไปตรงกับเลขบัตรจริงๆน่ะครับ จะชวนสับสนมากกว่า ว่าข้อมูลที่ได้รับนั้น ถูกเข้ารหัสมาแล้วจริงๆหรือไม่?
หมายถึงตรงกับเลขบัตรคนอื่น? ถ้าแบบนั้นเป็นไปได้แน่ๆ ครับ แต่ข้อมูลอื่นๆ (ชื่อ นามสกุล วันที่หมดอายุ) เมื่อเข้ารหัสแล้วโอกาสตรงก็ควรจะน้อยมาก จนเสมือนว่าเป็นศูนย์นะครับ
lewcpe.com, @wasonliw
เข้าใจครับว่า ถ้าเราไปจับคู่กับ key ตัวอื่นๆก็อาจจะทำให้แยกได้ ทว่าข้อมูลพวกนั้นก็น่าจะเป็นข้อมูลปกปิด(มันเลยเป็นปัญหากรณีใช้ Masking PAN เช่นกัน)
แต่สิ่งที่ข้องใจ คือเราจะทราบได้อย่างไรว่า ข้อมุลที่เรารับมานั้นถูกเข้ารหัสแล้ว?
เช่น เลขบัตรสมมติ 123456 เข้ารหัสแล้วกลายเป็น 567890 ซึ่งก็อาจไปตรงกับเลขบัตรของคนอื่นที่มีอยู่จริง ทำให้อาจเกิดความสับสนของผู้นำไปใช้ได้ว่า ข้อมุลที่ส่งมาเป็น Full PAN หรือเลขที่ถูก encypt ไปแล้วกันแน่? ผิดกับการเข้ารหัสแบบเก่า เช่น AES-256 ที่ออกมาแล้วเห็นชัดเจนว่ารูปแบบผลลัพธ์มันแตกต่างจากเดิมมากๆ
แต่FPEก็เป็นข้อดีที่อาจทำให้ผู้ที่ดักรับหรือขโมยข้อมูลเกิดความสับสนว่าเป็นข้อมูลจริงหรือข้อมูลลวง
ไม่ทราบสิครับ ต้องคุยกันเองระหว่างคนส่งข้อมูลกับคนรับข้อมูลว่าเข้ารหัสหรือยัง
กระบวนการเข้ารหัสทั้งหมดมันออกแบบมาเพื่อให้อยู่ในฟอร์แมตเดิม
จะบอกว่าไม่อยากคุยอะไรกันเลยแล้วให้แอปมันทำงานได้นี่คงเป็นไปไม่ได้ครับ FPE มันไม่ได้เป็นยาวิเศษแบบนั้น แต่ถ้าบอกว่าอยากประมวลผลโดยที่ซอฟต์แวร์มันออกแบบให้ handle ข้อมูลในรูปแบบเดียวไปแล้วแบบนี้คงแก้ปัญหาไปได้เยอะแล้ว
lewcpe.com, @wasonliw
เข้าใจประเด็นครับ ก็ยกตัวอย่างที่เกิดขึ้นจริง ว่าถ้าตรวจสอบได้ยากว่ามันถูกเข้ารหัสมาจริงๆหรือไม่ ข้อดีมันคือหลอกคนขโมยข้อมูล ข้อเสียคือถ้ามันหลุดจริงๆว่าไม่ได้เข้ารหัสไป กว่าจะรู้ตัวคงช้ากว่าปกติ ปัญหาพวกนี้เกิดขึ้นบ่อยๆโดยเฉพาะการส่งข้อมูลระหว่างหน่วยงานภายในกันเอง เลยคิดในแง่ร้ายว่าต้องทำ fool proof ไปด้วย
ก็เข้าใจประเด็นในเรื่องการรักษาformat ก็ทำให้ง่ายในการจัดเก็บด้วย
และยกมาว่าการmasking PAN มันไม่ unique การส่งไปประมวลผลข้างนอก อาจทำให้เกิดการนับซ้ำได้ง่ายๆ แต่ FPE ก็น่าจะมาช่วยตรงนี้ (เพราะ encrypt แล้วก็ unique แม้อาจจะดูไปซ้ำกับเลขจริงๆ)