ข้อผิดพลาดเช็คซัมคืออะไร? คู่มือการตรวจจับการเข้ารหัสลับ
ข้อผิดพลาดในการตรวจสอบผลรวม (checksum error) หมายความว่าข้อมูลไม่ผ่านการทดสอบทางคณิตศาสตร์ ในโลกคริปโต การทดสอบนั้นอ่อนแอกว่าที่ผู้ใช้ส่วนใหญ่คิดไว้มาก EIP-55 ของ Ethereum ตรวจจับข้อผิดพลาดได้ประมาณหนึ่งในสี่พันครั้ง Base58Check ของ Bitcoin แข็งแกร่งกว่าประมาณหนึ่งพันเท่า และ Bech32 แข็งแกร่งกว่านั้นอีก แต่การตรวจสอบผลรวมเหล่านั้นก็ไม่สามารถปกป้องกระเป๋าเงินดิจิทัลจากการโจมตีที่ทำให้เงิน 713 ล้านดอลลาร์สหรัฐฯ ไหลออกจากกระเป๋าเงินส่วนบุคคลในปี 2025 ได้ เพราะที่อยู่ที่เป็นอันตรายที่อยู่ในคลิปบอร์ดหรือในประวัติการทำธุรกรรมนั้นเป็นสตริงที่ถูกต้องและผ่านการทดสอบผลรวมแล้ว นี่คือความหมายของข้อผิดพลาดในการตรวจสอบผลรวม เหตุใดกระเป๋าเงินคริปโตจึงแสดงข้อผิดพลาดนี้ และเหตุใดการผ่านการทดสอบอย่างสมบูรณ์จึงไม่ใช่หลักฐานยืนยันความปลอดภัย
คำตอบสั้นๆ เกี่ยวกับข้อผิดพลาดเช็คซัมในระบบเข้ารหัสลับ
ข้อผิดพลาดเช็คซัมแจ้งให้ผู้ใช้ทราบว่าที่อยู่ ไฟล์ หรือวลีเริ่มต้นไม่ตรงกับการตรวจสอบความถูกต้องภายในระบบ กระเป๋าเงินดิจิทัล แพลตฟอร์มแลกเปลี่ยน หรือโปรแกรมติดตั้งปฏิเสธที่จะดำเนินการเนื่องจากบิตผิดเพี้ยน ตัวอักษรพิมพ์ผิด หรือข้อมูลถูกแก้ไข ในโลกคริปโต ข้อผิดพลาดนี้จะตรวจจับการพิมพ์ผิดและการเสียหายโดยไม่ได้ตั้งใจ แต่จะไม่สามารถตรวจจับที่อยู่ที่มีการพิมพ์ถูกต้องสมบูรณ์แบบซึ่งผู้โจมตีควบคุมอยู่ได้ การสูญเสียกระเป๋าเงินดิจิทัลครั้งใหญ่ที่สุดที่บันทึกไว้ในปี 2025 คือ 50 ล้านดอลลาร์สหรัฐใน USDT ในเดือนธันวาคม เกิดจากเหยื่อคัดลอกที่อยู่ที่มีเช็คซัมถูกต้องสมบูรณ์แบบ และที่อยู่นั้นเป็นของมิจฉาชีพ
เช็คซัมคืออะไร (และไม่ใช่อะไร) กันแน่
ลองนึกภาพเช็คซัมเป็นเหมือนใบเสร็จเล็กๆ สำหรับพัสดุขนาดใหญ่กว่ามาก ซึ่งเป็นบล็อกข้อมูลที่ถูกแฮชให้เหลือเพียงไม่กี่ไบต์ด้วยการคำนวณที่ทราบค่า ผู้ส่งจะแนบเช็คซัมต้นฉบับมาด้วย ผู้รับจะทำการคำนวณแบบเดียวกัน ได้เช็คซัมใหม่ และเปรียบเทียบกัน หากตรงกันหมายความว่าข้อมูลมีความถูกต้อง หากไม่ตรงกันหมายความว่าข้อมูลเสียหายที่ใดที่หนึ่ง เช่น บิตใน RAM เปลี่ยนไป การดาวน์โหลดถูกตัดขาดก่อนกำหนด หรือพิมพ์ผิด การไม่ตรงกันนี้เองที่โปรแกรมกระเป๋าเงินดิจิทัลและโปรแกรมติดตั้งจะแจ้งว่าเป็นข้อผิดพลาดของเช็คซัม ค่าเช็คซัมที่คำนวณได้ไม่ตรงกับค่าที่คาดหวังซึ่งแนบมากับข้อมูลต้นฉบับ (ค่าที่จัดเก็บไว้ซึ่งผู้ส่งได้เผยแพร่) ไม่มีข้อผิดพลาดของข้อมูลใดๆ หลุดรอดไปได้ เนื่องจากระบบตรวจจับข้อผิดพลาดและการตรวจสอบความถูกต้องขั้นพื้นฐานได้ทำงานแล้ว
ในเชิงกลไก การตรวจสอบความถูกต้องของข้อมูลแบบคลาสสิกนั้นเป็นการคำนวณทางคณิตศาสตร์ ไม่ใช่การเข้ารหัสลับ รูปแบบที่ง่ายที่สุดคือการแบ่งข้อมูลออกเป็นคำๆ แล้วทำการบวกด้วยส่วนเติมเต็มหนึ่ง (เทคนิค "ส่วนเติมเต็ม 1" ที่ใช้ในการตรวจสอบความถูกต้องของข้อมูล TCP/IP บนอินเทอร์เน็ตตั้งแต่ปี 1988) รูปแบบที่ซับซ้อนกว่าเล็กน้อย ได้แก่ การตรวจสอบความเท่าเทียมกันตามแนวยาว อัลกอริทึมของเฟลตเชอร์ และ CRC (การตรวจสอบความซ้ำซ้อนแบบวนรอบ) ซึ่งล้วนเป็นญาติกัน การตรวจสอบความซ้ำซ้อนแบบวนรอบนั้นรวดเร็วและเหมาะสำหรับข้อผิดพลาดในการส่งข้อมูล สำหรับการตรวจสอบความถูกต้องของไฟล์ในปัจจุบัน ตัวเลือกที่นิยมใช้คือ Adler-32 (เร็ว ไม่มีการเข้ารหัสลับ) หรือ MD5 หรือ SHA (ช้ากว่า แต่แข็งแกร่งกว่ามาก) เครื่องมือซอฟต์แวร์เช่น `sha256sum`, `md5sum` และ HashCheck เป็นวิธีที่ผู้ใช้ส่วนใหญ่ใช้ในการตรวจสอบความถูกต้อง
นี่คือขอบเขต เช็คซัมสามารถพิสูจน์ได้ว่าข้อมูลไม่ได้เสียหายหรือถูกแก้ไขโดยไม่ได้ตั้งใจในระดับไบต์เท่านั้น แค่นั้น มันไม่สามารถพิสูจน์ได้ว่าใครเป็นผู้สร้างข้อมูล SHA-256 ซึ่งเป็นแฮชเข้ารหัสลับนั้นแข็งแกร่งกว่า CRC มาก แต่ก็ยังไม่สามารถพิสูจน์ความเป็นเจ้าของได้ สำหรับการพิสูจน์ความเป็นเจ้าของนั้น ผู้เผยแพร่จะต้องลงนามในแฮชด้วยคีย์ส่วนตัว ผู้ใช้คริปโตมักสับสนระหว่างสองสิ่งนี้อยู่เสมอ "ที่อยู่ผ่านการตรวจสอบเช็คซัม" ไม่เหมือนกับ "ที่อยู่เป็นของบุคคลที่ถูกต้อง" ใครๆ ก็สามารถสร้างที่อยู่ Ethereum หรือ Bitcoin ที่ถูกต้องได้ มีเพียงผู้ถือคีย์ส่วนตัวเท่านั้นที่ควบคุมเงินทุน การตรวจสอบเช็คซัมยืนยันว่าที่อยู่ถูกต้อง แต่ชี้ไปยังกระเป๋าเงินของใคร? นั่นเป็นคำถามที่แตกต่างออกไป และมีคำตอบที่แตกต่างกัน
วิธีการทำงานของอัลกอริธึมตรวจสอบความถูกต้องของข้อมูลเข้ารหัส: EIP-55, Base58Check, Bech32
มีรูปแบบธุรกิจหลักสามรูปแบบที่ครองตลาดคริปโตเคอร์เรนซีสำหรับผู้ค้าปลีก และแต่ละรูปแบบได้รับการออกแบบโดยมีลำดับความสำคัญที่แตกต่างกัน
EIP-55 คือ checksum แบบผสมตัวพิมพ์ใหญ่-เล็กของ Ethereum Vitalik Buterin และ Alex Van de Sande เสนอแนวคิดนี้เมื่อวันที่ 14 มกราคม 2016 หลักการทำงานคือ การแปลงที่อยู่ให้เป็นตัวพิมพ์เล็กทั้งหมด จากนั้นทำการแฮชสตริงที่แปลงเป็นตัวพิมพ์เล็กแล้วด้วย Keccak-256 และแปลงตัวอักษรฐานสิบหก (A–F) กลับเป็นตัวพิมพ์ใหญ่ตามบิตของค่าแฮชนั้น เฉพาะตัวอักษรฐานสิบหก 15 ตัวในที่อยู่ทั่วไปเท่านั้นที่จะสามารถเปลี่ยนตัวพิมพ์ได้ ทำให้ระบบมีบิตตรวจสอบที่มีประสิทธิภาพประมาณ 15 บิต EIP-1191 ซึ่งเสนอในเดือนมีนาคม 2018 ได้ขยาย EIP-55 ด้วยรหัสเชน (chain ID) เพื่อป้องกันไม่ให้ checksum ที่อยู่บน Ethereum และบนเชนที่แยกออกมา เช่น Rootstock เกิดการชนกัน
Base58Check เป็นระบบตรวจสอบความถูกต้องแบบดั้งเดิมของ Bitcoin โดยจะเพิ่มค่าตรวจสอบความถูกต้อง 4 ไบต์ต่อท้ายที่อยู่ที่มีการเข้ารหัส ซึ่งคำนวณจาก 4 ไบต์แรกของค่า SHA-256 สองเท่าของไบต์เวอร์ชันบวกกับข้อมูลหลัก คำนำหน้า "1" ในที่อยู่ P2PKH จะตรงกับไบต์เวอร์ชัน 0x00 และคำนำหน้า "3" ในที่อยู่ P2SH จะตรงกับ 0x05 ตัวอักษร Base58 เองจะตัดตัวอักษร 0, O, I และ L ที่อาจทำให้สับสนออกไป การคำนวณค่าตรวจสอบความถูกต้องสำหรับ Base58Check นั้นทำได้ง่ายๆ โดยการเรียกใช้ SHA-256 เพียงครั้งเดียว ตามด้วยการเปรียบเทียบ 4 ไบต์
Bech32 (BIP-173) เป็นรูปแบบการกำหนดแอดเดรส SegWit จาก Pieter Wuille และ Greg Maxwell ในปี 2017 รหัส BCH 6 ตัวอักษรของมันรับประกันการตรวจจับข้อผิดพลาดทุกอย่างที่ส่งผลกระทบต่อตัวอักษรได้สูงสุดสี่ตัว และรักษาอัตราข้อผิดพลาดที่ไม่ถูกตรวจพบให้ต่ำกว่าหนึ่งในพันล้านสำหรับการเสียหายที่ยาวขึ้น การค้นพบที่ละเอียดอ่อนในปี 2020 (ว่าการแทรกหรือลบ 'q' ก่อน 'p' ตัวสุดท้ายสามารถรักษาค่าตรวจสอบความถูกต้องได้) เป็นแรงบันดาลใจให้เกิด BIP-350 Bech32m ซึ่ง Taproot (witness เวอร์ชัน 1) ใช้ในปัจจุบัน
| โครงการ | ปี | ตัวอย่างที่อยู่ | ตรวจสอบขนาด | การตรวจจับคำผิดทั่วไป |
|---|---|---|---|---|
| อีไอพี-55 / อีไอพี-1191 | 2016/2018 | `0xAbCd...EfGh` | ประมาณ 15 บิต | ~99.97% (พลาด 1 ใน 4,000 ครั้ง) |
| Base58Check (P2PKH) | 2009 | `1A1zP1...` | 32 บิต | ~99.99999998% |
| Base58Check (P2SH) | 2012 | `3J98t1...` | 32 บิต | ~99.99999998% |
| Bech32 (SegWit v0) | 2017 | `bc1q...` | ประมาณ 30 บิต | ≥99.999999999% สำหรับข้อผิดพลาด 4 ตัวอักษร |
| Bech32m (รากแก้ว) | 2020 | `bc1p...` | ประมาณ 30 บิต | เหมือนกัน แก้ไขปัญหาการแทรก qp |
ตารางดังกล่าวเป็นตัวเลขที่สำคัญที่สุดในบทความนี้ โปรดพิจารณาตัวเลขเหล่านี้ในฐานะงบประมาณในการออกแบบ ไม่ใช่การรับประกันความปลอดภัย
เหตุใด EIP-55 จึงตรวจพบข้อผิดพลาดในการพิมพ์เพียง 1 ใน 4,000 ครั้ง
ข้อกำหนด EIP-55 ระบุอัตราความล้มเหลวไว้อย่างชัดเจน: ความน่าจะเป็นที่การพิมพ์ผิดแบบสุ่มในที่อยู่ Ethereum จะผ่านการตรวจสอบ checksum คือ 0.0247 เปอร์เซ็นต์ หรือประมาณหนึ่งใน 4,049 นี่ไม่ใช่ข้อผิดพลาด แต่เป็นสิ่งที่บิตตรวจสอบที่มีประสิทธิภาพ 15 บิตมอบให้ ระบบนี้เป็นการปรับปรุงในปี 2016 ออกแบบมาให้เข้ากันได้กับรูปแบบที่อยู่เลขฐานสิบหก 40 ตัวอักษรที่มีอยู่เดิม ความเข้ากันได้นั้นส่งผลต่อความแม่นยำในการตรวจจับ
สำหรับการใช้งานกระเป๋าเงินดิจิทัลทั่วไปนั้น โดยปกติแล้วก็ไม่มีปัญหาอะไร ผู้ใช้ที่พิมพ์หรือวางที่อยู่เพียงครั้งเดียว มีโอกาสสูงมากที่จะถูกจับได้หากพลาดพลั้ง แต่ผู้ใช้ที่วางที่อยู่ที่มีการปลอมแปลงซ้ำกันสิบครั้งติดต่อกัน จะผ่านการตรวจสอบความถูกต้องทุกครั้ง เพราะที่อยู่ดังกล่าวถูกต้อง ความแตกต่างนับพันเท่าระหว่างการตรวจสอบความถูกต้องของที่อยู่ Ethereum กับ Base58Check ของ Bitcoin และขั้นตอนที่สูงขึ้นไปอีกขั้นกับ Base32 คือเหตุผลที่ทำให้ UX ของกระเป๋าเงินดิจิทัลที่จริงจังถือว่าการตรวจสอบความถูกต้องของที่อยู่ Ethereum เป็นความรับผิดชอบของผู้ใช้มากกว่าความรับผิดชอบของโปรโตคอล
ข้อผิดพลาดในการตรวจสอบค่าตรวจสอบความถูกต้อง (Checksum errors) ที่อยู่นอกเหนือการเข้ารหัส: WinRAR, BIOS, เฟิร์มแวร์, ฮาร์ดไดรฟ์
คนส่วนใหญ่ที่พิมพ์ "checksum error" ลงใน Google ไม่ใช่ผู้ใช้งานด้านการเข้ารหัสลับ พวกเขาอาจกำลังจ้องมองโปรแกรม WinRAR หรือหน้าจอบูตเครื่องพีซีที่ค้าง หรือ NAS ที่มีปัญหา คำศัพท์เหมือนกัน แต่ความเสี่ยงแตกต่างกันอย่างสิ้นเชิง
WinRAR คือโปรแกรมคลาสสิกที่ใช้กันมานานแล้ว คุณดาวน์โหลดไฟล์ .rar แล้วแตกไฟล์ออกมา ก็จะเจอป๊อปอัพแจ้งว่า CRC ไม่ตรงกัน แสดงว่าไฟล์เสียหาย โดยปกติสาเหตุมักเป็นเรื่องธรรมดา เช่น การดาวน์โหลดถูกขัดจังหวะ การเชื่อมต่อ Wi-Fi ไม่เสถียร เซกเตอร์เสียบนดิสก์ หรือบางครั้งอาจเป็นมัลแวร์ที่เข้ามาแก้ไขไฟล์ระหว่างการแตกไฟล์ ให้ดาวน์โหลดใหม่จากแหล่งที่มาเดิม หรือใช้โปรแกรม CHKDSK ตรวจสอบ ถ้าคุณจำเป็นต้องกู้ข้อมูลที่เหลืออยู่จริงๆ ตัวเลือก "เก็บไฟล์ที่เสียหาย" ของ WinRAR จะแตกไฟล์สำเนาบางส่วนของเนื้อหาออกมาให้
ข้อผิดพลาดในการตรวจสอบความถูกต้องของ BIOS หรือ CMOS ระหว่างการบูตเครื่องพีซี มักเกิดจากแบตเตอรี่ CR2032 บนเมนบอร์ดหมดไฟ บางครั้งการอัปเดตเฟิร์มแวร์ที่ล้มเหลวอาจทำให้ NVRAM เสียหาย หรือบางครั้งผู้ใช้ถอดแรมออกและลายนิ้วมือฮาร์ดแวร์ที่บันทึกไว้ไม่ตรงกัน ให้ใส่แบตเตอรี่กลับเข้าไป โหลดค่าเริ่มต้น เครื่องก็จะบูตได้
ระบบไฟล์ ZFS และ Btrfs จะแสดงข้อผิดพลาดเกี่ยวกับค่าตรวจสอบความถูกต้อง (checksum error) เมื่อฮาร์ดไดรฟ์ส่งคืนบล็อกที่ไม่ตรงกับค่าแฮชที่จัดเก็บไว้ ข้อผิดพลาดเหล่านี้เป็นไปตามเจตนารมณ์ของการออกแบบโดยแท้จริง นั่นคือ การเสื่อมสภาพของข้อมูลที่เกิดขึ้นอย่างเงียบๆ ได้ถูกเปิดเผยออกมาในที่สุด
สิ่งที่ควรทำให้ผู้ใช้คริปโตเคอร์เรนซีรู้สึกกังวลคือข้อผิดพลาดในการตรวจสอบความถูกต้องของเฟิร์มแวร์ในฮาร์ดแวร์วอลเล็ต บูตโหลดเดอร์ของ Trezor จะตรวจสอบลายเซ็นเฟิร์มแวร์อีกครั้งทุกครั้งที่บูตเครื่อง ส่วนประกอบรักษาความปลอดภัยของ Ledger ก็ทำเช่นเดียวกัน ข้อความ "ลายเซ็นไม่ถูกต้อง" หรือ "ข้อผิดพลาดที่ไม่รู้จัก (0x6984)" ของ Ledger ที่แสดงขึ้นระหว่างการติดตั้ง คือสัญญาณเตือนจากอุปกรณ์ว่าเฟิร์มแวร์ที่พบไม่ตรงกับสิ่งที่คีย์หลักคาดหวัง หยุดทันที ถอดปลั๊ก แล้วดาวน์โหลดใหม่จาก URL ของผู้จำหน่ายที่คุณจำได้ขึ้นใจ ใครก็ตามที่คลิกผ่านคำเตือนนั้นก็เท่ากับก้าวเข้าสู่ช่องโหว่ของการโจมตีห่วงโซ่อุปทานแล้ว
เมื่อใดที่ข้อผิดพลาดในการตรวจสอบผลรวมบ่งชี้ว่ามีการดัดแปลงแก้ไข และเมื่อใดที่ไม่ใช่
ประเด็นสำคัญในบทความนี้คือ การตรวจสอบความถูกต้องของข้อมูล (Checksum) ตรวจจับความเสียหายแบบสุ่มได้ดี แต่ไม่สามารถป้องกันผู้โจมตีที่เลือกใช้ที่อยู่เว็บที่ถูกต้องโดยเจตนาได้
รายงานอาชญากรรมคริปโต 2026 ของ Chainalysis ระบุว่า การโจรกรรมคริปโตโดยรวมในปี 2025 จะมีมูลค่า 3.4 พันล้านดอลลาร์ โดย 1.5 พันล้านดอลลาร์มาจากการแฮ็ก Bybit เพียงครั้งเดียว กระเป๋าเงินดิจิทัลส่วนบุคคลสูญเสียเงินไป 713 ล้านดอลลาร์ จากผู้เสียหายประมาณ 80,000 ราย ในเหตุการณ์ประมาณ 158,000 ครั้ง แทบไม่มีการสูญเสียใด ๆ ที่เกิดจาก checksum ที่ไม่ถูกต้องเนื่องจากพิมพ์ผิด เพราะเว็บเทรดและกระเป๋าเงินดิจิทัลจะตรวจสอบความถูกต้องของ checksum เหล่านั้นที่ช่องป้อนข้อมูล การสูญเสียส่วนใหญ่มาจากสองการโจมตีที่ checksum ที่ถูกต้องไม่สามารถป้องกันได้
วิธีแรกคือการโจมตีด้วยการวางยาพิษที่อยู่ (Address Poisoning) ผู้โจมตีจะส่งธุรกรรมขนาดเล็กมากจากที่อยู่ใหม่ที่สร้างขึ้นโดยตั้งใจให้มีตัวอักษรแรกและตัวอักษรสุดท้ายคล้ายกับคู่ค้าที่เหยื่อใช้บ่อย ครั้งต่อไปที่เหยื่อคัดลอกที่อยู่จากประวัติการทำธุรกรรม ที่อยู่ปลอมนั้นจะปรากฏอยู่ด้านบนสุดของรายการ ที่อยู่ดังกล่าวมีค่าตรวจสอบความถูกต้อง (checksum) ที่ถูกต้องสมบูรณ์ กระเป๋าเงินจะแสดงยอดเงินสีเขียว และเงินจะตกเป็นของผู้โจมตี ข้อมูลจาก Chainalysis ที่อ้างอิงโดย Carnegie Mellon ระบุว่าในปี 2025 มีการพยายามโจมตีด้วยการวางยาพิษที่อยู่ถึง 270 ล้านครั้ง โดยมีเป้าหมายที่เหยื่อ 17 ล้านราย เหตุการณ์เมื่อวันที่ 20 ธันวาคม 2025 ที่เทรดเดอร์รายหนึ่งสูญเสียเงิน 50 ล้านดอลลาร์สหรัฐใน USDT เกิดขึ้นประมาณ 26 นาทีหลังจากที่เหยื่อส่งธุรกรรมทดสอบขนาดเล็ก การทดสอบนั้นไม่ได้ช่วยอะไรพวกเขา เพราะที่อยู่ปลอมได้ถูกบันทึกไว้ในประวัติแล้ว
ประการที่สองคือแฮกเกอร์ที่ขโมยข้อมูลในคลิปบอร์ด มัลแวร์อย่างเช่นแคมเปญ GitVenom ที่ Kaspersky เคยบันทึกไว้ จะทำการสลับที่อยู่คริปโตที่คัดลอกไปยังคลิปบอร์ดโดยที่ผู้โจมตีควบคุมอยู่โดยไม่ให้ผู้โจมตีรู้ตัว ความเสียหายที่ประเมินจาก GitVenom เพียงอย่างเดียวสูงถึงประมาณ 485,000 ดอลลาร์สหรัฐในช่วงปลายปี 2024 โดยมีเหยื่อในบราซิล ตุรกี และรัสเซีย อีกครั้ง ที่อยู่คริปโตที่ถูกแทนที่นั้นมีค่าตรวจสอบความถูกต้อง (checksum) ที่ถูกต้อง กระเป๋าเงินดิจิทัลจึงไม่มีอะไรให้ต้องสงสัย ข้อมูลสำคัญ เช่น ปลายทางของการโอนเงินจำนวนมาก จึงหลุดรอดการตรวจสอบความปลอดภัยไปได้ เพราะมันไม่เคยถูกเปลี่ยนแปลงหรือเสียหาย เพียงแต่ถูกแทนที่ด้วยข้อมูลที่ถูกต้องเช่นกัน
| การโจมตีปี 2025 | กลไก | การตรวจสอบผลรวมรหัสช่วยหยุดมันไว้หรือเปล่า? |
|---|---|---|
| การวางยาพิษที่อยู่ (50 ล้านดอลลาร์สหรัฐ, 20 ธันวาคม 2025) | ที่อยู่ปลอมแปลงที่ดูคล้ายกันในประวัติการทำธุรกรรม | ไม่ — ที่อยู่ IP ที่ปลอมแปลงนั้นมีค่าตรวจสอบ EIP-55 ที่ถูกต้อง |
| โปรแกรมแฮ็กคลิปบอร์ด (GitVenom, ประมาณ 485,000 ดอลลาร์สหรัฐ) | มัลแวร์จะแทนที่ที่อยู่เว็บที่คัดลอกมา | ไม่ ที่อยู่ที่แก้ไขแล้วนั้นถูกต้อง |
| การหลอกลวงโดยใช้บอท MEV ในรูปแบบ ChatGPT (>30 ETH, >100 เหยื่อ) | สัญญาที่แนะนำโดย AI ทำให้เงินในกระเป๋าหมดไป | ไม่ — เช็คซัมไม่มีคุณสมบัติใดที่จะยืนยันเจตนาของสัญญาได้ |
| การหลอกลวงโดยใช้ AI ช่วยเหลือโดยทั่วไป | ให้ผลกำไรมากกว่าโครงการแบบดั้งเดิมถึง 4.5 เท่า | ไม่ — วิธีนี้อาศัยการโน้มน้าวทางสังคม ไม่ใช่การแก้ไขข้อผิดพลาดในการพิมพ์ |
ผลรวมตรวจสอบสีเขียวหมายความว่าที่อยู่ถูกต้องตามรูปแบบ แต่ไม่ได้หมายความว่าเป็นที่อยู่ของคุณ ความแตกต่างนี้เป็นสิ่งสำคัญที่สุดที่ผู้ใช้คริปโตเคอร์เรนซีควรจดจำจากบทความนี้
วลีเริ่มต้น BIP-39: เหตุใดคำที่ถูกต้องจึงยังไม่ผ่านการตรวจสอบผลรวม
วลีรหัส BIP-39 ยังมีค่าตรวจสอบความถูกต้อง (checksum) ด้วย ซึ่งทำให้หลายคนประหลาดใจระหว่างการกู้คืนข้อมูล ระบบนี้จะเข้ารหัสบิตสุดท้ายไม่กี่บิตของ SHA-256 ผ่านเอนโทรปีของกระเป๋าเงินไปยังคำสุดท้ายของวลี รหัส 12 คำจะมีค่าตรวจสอบความถูกต้องเพียง 4 บิต รหัส 24 คำจะมี 8 บิต สำหรับ 12 คำ นั่นหมายความว่าจะมีเพียงประมาณหนึ่งในสิบหกของคำสุดท้ายที่สุ่มเลือกมาเท่านั้นที่จะผ่านการตรวจสอบความถูกต้อง ประโยคที่ว่า "ฉันแน่ใจว่ารหัสของฉันถูกต้อง แต่กระเป๋าเงินปฏิเสธ" ส่วนใหญ่แล้วมักเกิดจากพิมพ์ผิดในส่วนต้นของวลี หรือเป็นคำที่ไม่ถูกต้องจากรายการคำ 2,048 คำของ BIP-39
ในส่วนของฮาร์ดแวร์นั้นเข้มงวดกว่า Trezor และ Ledger จะตรวจสอบลายเซ็นเฟิร์มแวร์อีกครั้งทุกครั้งที่บูตเครื่องผ่านโค้ดส่วนประกอบความปลอดภัย ไม่ใช่ที่เครื่องโฮสต์ หากลายเซ็นไม่ตรงกันจะถือว่าเป็นการดัดแปลง และเฟิร์มแวร์จะไม่สามารถทำงานได้ ซึ่งเป็นพฤติกรรมที่ถูกต้อง ใครก็ตามที่พบข้อผิดพลาดเกี่ยวกับ checksum หรือลายเซ็นของเฟิร์มแวร์จากกระเป๋าเงินฮาร์ดแวร์ ควรพิจารณาว่าเป็นสัญญาณเตือน ไม่ใช่ความผิดพลาด
วิธีตรวจสอบและแก้ไขข้อผิดพลาดของค่าตรวจสอบความถูกต้อง (checksum): แนวทางปฏิบัติที่ดีที่สุด
รายการตรวจสอบนั้นสั้น และเหมือนกันในกระเป๋าเงินดิจิทัลและแพลตฟอร์มแลกเปลี่ยนส่วนใหญ่
ที่อยู่ Ethereum คัดลอกจากช่องทางที่ได้รับการยืนยันของคู่กรณี (โปรไฟล์ที่เผยแพร่ ไม่ใช่ข้อความส่วนตัวใน Telegram) วางลงไป รอให้กระเป๋าเงินตรวจสอบความถูกต้อง ส่งเงิน 1 ดอลลาร์เป็นธุรกรรมทดสอบ รอการยืนยัน จากนั้นส่งจำนวนเงินเต็มจำนวน Kraken จะจัดเก็บที่อยู่ ETH ที่บันทึกไว้ทุกที่อยู่ในรูปแบบ EIP-55 โดยค่าเริ่มต้น Binance และ Coinbase จะปฏิเสธการป้อนข้อมูล checksum ที่ไม่ถูกต้องในขั้นตอนการส่ง ก่อนที่การกระจายข้อมูลใดๆ จะส่งไปยังบล็อกเชน MetaMask จะใช้ EIP-55 เป็นค่าเริ่มต้นและแสดงคำเตือนสำหรับที่อยู่ที่มีการแก้ไขด้วยตนเอง ในอดีตมันยอมรับตัวพิมพ์เล็กทั้งหมดด้วย ซึ่งมีปัญหาที่เปิดอยู่บน GitHub หลายแห่งที่บ่นเกี่ยวกับเรื่องนี้มานานหลายปีแล้ว
ที่อยู่ Bitcoin ควรใช้ Bech32 (`bc1...`) แทนรูปแบบ `1...` และ `3...` แบบเดิม เมื่อคู่กรณีรองรับ เนื่องจากความสามารถในการตรวจจับข้อผิดพลาดสูงกว่าอย่างเห็นได้ชัด และรูปแบบที่อยู่ก็อ่านผิดได้ยากกว่า
ดาวน์โหลดไฟล์ ไบนารีของกระเป๋าเงินดิจิทัล อิมเมจเฟิร์มแวร์ของกระเป๋าเงินฮาร์ดแวร์ หรือไฟล์ ISO ของ Linux คำนวณค่าแฮช SHA-256 ในเครื่องของคุณเอง เปรียบเทียบกับค่าที่ผู้เผยแพร่ ลงนามไว้ ไม่ใช่ค่าที่พิมพ์อยู่ข้างลิงก์ดาวน์โหลด เพราะผู้บุกรุกที่ควบคุมหน้าดาวน์โหลดสามารถสลับทั้งสองค่าได้ เก็บสำเนาสำรองของไฟล์ที่ตรวจสอบแล้วที่คุณใช้งานจริงไว้ การตรวจจับข้อผิดพลาดในภายหลังจะง่ายขึ้นมากเมื่อมีสำเนาที่ถูกต้องอยู่ในแฟลชไดรฟ์ USB หรือเอกสารที่พิมพ์ออกมา
เฟิร์มแวร์ของกระเป๋าเงินฮาร์ดแวร์มีข้อผิดพลาดในการตรวจสอบความถูกต้องของข้อมูลหรือลายเซ็น อย่าข้ามขั้นตอนนี้ ดาวน์โหลดใหม่จาก URL ที่ผู้ผลิตระบุไว้ ลองใช้สายเคเบิลอื่น ลองใช้พอร์ต USB อื่น รีสตาร์ท Ledger Live หรือ Trezor Suite หากยังคงมีข้อผิดพลาดอยู่ ให้ส่งอีเมลไปที่ฝ่ายสนับสนุนของผู้ผลิต การค้นหา "แก้ไข Ledger 0x6984" ในฟอรัมของบุคคลที่สามเป็นที่ที่แฮกเกอร์รออยู่
ประโยคเดียวที่ควรจำไว้คือ การตรวจสอบความถูกต้องของข้อมูล (checksum) ผ่านเกณฑ์นั้น หมายความว่าข้อมูลไม่ได้เสียหายโดยไม่ได้ตั้งใจ แต่ไม่ได้หมายความว่าข้อมูลนั้นตรงกับสิ่งที่คุณต้องการส่งไป
