SecurePair คืออะไร?

SecurePair เป็น Arduino Library สำหรับสร้างความสัมพันธ์ระหว่าง ESP32 เพื่อให้ Device สามารถตกลง Key ใหม่ระหว่างกัน แล้วใช้ Key นั้นสำหรับส่งข้อความ ที่ถูกเข้ารหัสและตรวจสอบความถูกต้อง

Pain Point ที่ Project นี้พยายามแก้คือ: ถ้า Device ไม่มีหน้าจอ ไม่มี Keyboard และไม่อยากฝัง Shared Password เดียวกันลง Firmware ทุกเครื่อง เราจะทำให้สอง Device รู้จักกันอย่างปลอดภัยได้อย่างไร?

SecurePair เลือกใช้ LED และปุ่มกด เป็น Human Interface ขั้นต่ำ โดยไม่ต้องมี App, QR Code, Keyboard หรือ Password สำหรับการ Pairing

ก่อนอื่นต้องแยก SecurePair กับ PacketLED ออกจากกัน

จุดนี้สำคัญมาก เพราะถ้าอ่านเฉพาะ Headline อาจเข้าใจว่า SecurePair คือ Library สำหรับสื่อสารผ่าน LED อย่างเดียว

ข้อดีของ Architecture แบบนี้คือ Pairing Transport กับ Message Transport ไม่จำเป็นต้องเป็นตัวเดียวกัน

LED ดวงเดียวส่งและรับข้อมูลได้ยังไง?

เวลาใช้งานตามปกติ LED เปลี่ยนกระแสไฟฟ้าเป็นแสง

แต่ Junction ภายใน LED สามารถตอบสนองต่อแสงที่ตกกระทบได้เช่นกัน ทำให้ LED ถูกใช้เป็น Light Sensor แบบง่าย ๆ ได้

PacketLED ใช้หลักการนี้โดย:

ดังนั้น Hardware ตัวเดียวกัน สามารถสลับ Role ระหว่าง:

• Emitter — เปิด LED เพื่อส่ง Bit
• Sensor — อ่าน Light Level เพื่อรับ Bit

Hardware และการต่อ LED ใช้อะไรบ้าง?

สำหรับ Optical Link PacketLED ระบุ Hardware ขั้นต่ำต่อ Board:

• ESP32 Board
• LED 1 ดวง
• Resistor 1 ตัว

ส่วน SecurePair Workflow ต้องมี Input สำหรับตอบ Yes / No ซึ่ง Example ใช้ Push Button

LX.25 ทำให้การกระพริบ LED กลายเป็น Packet Link ได้อย่างไร?

PacketLED ไม่ได้ส่งข้อมูลด้วยการ “เปิดไฟแทน 1 ปิดไฟแทน 0” แบบตรง ๆ เพียงอย่างเดียว

Library มี Link Protocol ชื่อว่า LX.25 ซึ่งได้แรงบันดาลใจจาก AX.25 Packet Radio

Packet หนึ่งรองรับ Payload:

และมี:

• CRC-16/X.25
• Acknowledgement
• Retransmission สูงสุดตาม Protocol
• Duplicate Filtering
• Listen-before-transmit
• Random Delay ก่อน Retry

Bit ถูก Manchester-coded:

• 0 = Light → Dark
• 1 = Dark → Light

Receiver จึงเปรียบเทียบ Light Level ของสองช่วงในแต่ละ Bit ช่วยลดผลกระทบจาก Ambient Light คงที่ และ Slow Flicker เช่นแสงจากระบบไฟฟ้า 50 Hz

ความเร็วและระยะของ PacketLED เท่าไร?

PacketLED รองรับ Bit Rate:

• 256 bit/s
• 512 bit/s
• 1024 bit/s

แต่ระยะไม่ได้มีตัวเลขเดียว เพราะขึ้นกับ LED, Beam Angle, Current, Ambient Light และการจัดแนว

ทำไม SecurePair เลือกใช้แสงตอน Pairing?

Radio สะดวก แต่มีคุณสมบัติหนึ่งที่ไม่เหมาะกับการ Pair Device ที่ต้องการ Physical Proximity: คนที่อยู่ในระยะ Radio ไม่จำเป็นต้องยืนอยู่ตรงหน้าเรา

แสงมี Boundary ทางกายภาพชัดกว่า:

• ต้องมี Line of Sight
• LED ต้องหันเข้าหากัน
• แสงไม่ทะลุกำแพงเหมือน Radio
• การเข้ามาแทรก Optical Path ทำได้ยากขึ้นในทางกายภาพ

Pairing จริง ผู้ใช้ต้องทำอะไรบ้าง?

SecurePair ออกแบบขั้นตอน ให้ Device ที่ไม่มีหน้าจอ ยังสามารถให้มนุษย์ยืนยัน Pairing ได้

ถ้า Pattern ต่างกัน Source กำหนดให้ผู้ใช้ Reject แทนการบันทึก Key

การ Pair ใหม่ภายหลัง สามารถใช้เพื่อแทนที่ Key ของ Peer ที่รู้จักอยู่แล้วได้

20 Blink Code เอาไว้ป้องกันอะไร?

หลังการแลก Key SecurePair สร้าง Short Authentication String หรือ SAS ขนาด 20 bit

เมื่อใช้ Plain LED Code จะถูกแสดงเป็น:

Protocol ระบุแต่ละ Slot 500 ms ทำให้ Code Window รวมประมาณ 10 วินาที

ผู้สร้างระบุว่า Commitment Scheme ทำให้โอกาสที่ผู้โจมตีแบบ Man-in-the-Middle จะสร้าง SAS ให้ตรงทั้งสองฝั่งโดยบังเอิญอยู่ที่:

X25519, HKDF และ AES-256-GCM ทำหน้าที่ต่างกันยังไง?

SecurePair ไม่ได้สร้าง Encryption Algorithm ใหม่ขึ้นเอง แต่ประกอบ Protocol จาก Cryptographic Primitive มาตรฐานหลายตัว

X25519 และ AES-GCM ใช้ Implementation จาก Mbed TLS ที่มากับ ESP32 Core ตาม Repository

ส่วน Message Direction แต่ละฝั่ง ได้ AES-GCM Key แยกจากกัน เพื่อหลีกเลี่ยงปัญหา การใช้ Nonce ซ้ำระหว่างสองทิศทาง

Pair ด้วย LED แล้วทำไมคุยต่อผ่าน ESP-NOW ได้?

SecurePair แยก Pairing Transport ออกจาก Message Transport

ตัวอย่างที่น่าสนใจที่สุดคือ:

ดังนั้น LED สามารถทำหน้าที่ เหมือน Physical Provisioning Interface ที่ใช้เพียงตอนนำ Device มา Pair กัน

ทำไม PacketLED ส่งได้ 64 Bytes แต่ SecurePair เหลือ 35 Bytes?

PacketLED ดิบ รองรับ Payload สูงสุด 64 bytes

แต่ SecureLink ต้องเพิ่ม Security Metadata เข้าไปใน Frame:

รวม Fixed Overhead: 29 bytes

นี่เป็นตัวอย่างที่ดีว่า Encryption และ Authentication ไม่ได้เกิดขึ้นแบบ “ฟรี” แต่มี Protocol Overhead เพิ่มเข้ามา

Encrypted อย่างเดียวไม่พอ ทำไม SecurePair ต้องกัน Replay?

สมมติ Attacker อ่านเนื้อหาข้อความไม่ได้ แต่ Record Packet คำสั่ง “เปิดประตู” ไว้ได้

ถ้าระบบยอมรับ Packet เดิมซ้ำ Encryption อย่างเดียว ก็ไม่ได้แก้ปัญหานี้

SecurePair จึงใช้:

• Boot Epoch
• Message Counter
• Replay Window ต่อ Peer
• Challenge / Proof หลัง Receiver Reboot ในบางกรณี

Repository ระบุว่า Counter เดิมไม่ควรถูกใช้ซ้ำกับ Key เดิม เพราะ AES-GCM ต้องหลีกเลี่ยง Nonce Reuse

Board เดียว Pair ได้กี่อุปกรณ์?

Hackaday ระบุถูกต้องว่า Project ไม่ได้จำกัดอยู่แค่ ESP32 สองตัว

Current SecurePair README ให้ตัวเลขชัดกว่า:

Peer แต่ละตัวมี Identity และ Key ของตัวเอง

ถ้า Pair กับ Device เดิมใหม่ SecurePair จะ Replace Key ของ Peer เดิม แทนการสร้าง Record ซ้ำอีกตัว

Key ถูกเก็บไว้ที่ไหน?

SecurePair ใช้ ESP32 NVS สำหรับเก็บ Peer Record และ Key เพื่อให้ข้อมูล Pairing อยู่ต่อหลัง Reset

แต่มี Caveat สำคัญ:

สำหรับ ESP32 Variant ที่มี HMAC Peripheral SecurePair รองรับการสร้าง Device-specific Chip Key แล้วใช้ Key นั้น ใน Workflow สำหรับ Seal Peer Records

Repository ระบุ HMAC-capable Chip สำหรับ Feature นี้ ได้แก่:

• ESP32-S2
• ESP32-S3
• ESP32-C3
• ESP32-C5
• ESP32-C6
• ESP32-H2
• ESP32-P4

AES-256 ไม่ได้แปลว่าทุก Attack ถูกปิดหมด — SecurePair มีข้อจำกัดอะไรบ้าง?

Repository เปิดเผย Known Limitations ค่อนข้างตรงไปตรงมา

ผู้ใช้ Confirm โดยไม่ดู Code

Human Verification เป็นส่วนหนึ่งของ Security Model ถ้าผู้ใช้กด Confirm โดยไม่ตรวจ Pattern การป้องกัน MITM จะอ่อนลง

ไม่มี Forward Secrecy สำหรับ Message History

SecurePair ระบุว่า Stored Message Key ไม่มี Forward Secrecy ดังนั้นถ้า Key ถูกอ่านได้ในภายหลัง ข้อความเก่าที่ถูก Record ไว้ อาจถูกถอดได้

Flash Rollback

Repository ระบุว่า การเขียน Flash Image เวอร์ชันเก่ากลับลงไป ยังไม่ถูก Detect และอาจทำให้ State บางส่วนย้อนกลับ

Attacker รัน Code บน Chip ได้

Chip-bound Storage ไม่ได้ป้องกัน Code ที่ผู้โจมตี สามารถรันบน MCU ตัวเดิมได้โดยอัตโนมัติ เพราะ Code บน Chip อาจเข้าถึง Hardware Security Peripheral ได้เช่นกัน

Randomness ตอน Radio Off

Repository ระบุว่า ขณะ Pairing ผ่าน LED Radio ถูกปิด และ esp_random() ไม่ใช่ Full-entropy Source ในเงื่อนไขนั้น

Library จึง Mix ESP32 Random, CPU Timing และ Noise จากการอ่าน LED ผ่าน SHA-256

Status Beta 0.5.0 สำคัญอย่างไร?

Current library.properties ที่ตรวจระบุ SecurePair:

Hardware ที่ Repository ระบุว่าทดสอบแล้ว:

• ESP32
• ESP32-C3
• ESP32-C6

มีการทดสอบ:

• Pairing ผ่าน LED
• Pairing ผ่าน ESP-NOW
• Message ผ่าน LED
• Message ผ่าน ESP-NOW
• Re-pairing
• Encrypted Storage

แต่:

Source Code Example: Pair ผ่าน LED แล้วคุยผ่าน ESP-NOW

จุดที่เห็น Architecture ของ SecurePair ได้ชัดที่สุดคือ Pairing Transport กับ Message Transport ถูกกำหนดแยกกัน

#include <PacketLED.h>
#include <SecurePairLed.h>
#include <transport/EspNowTransport.h>

ArduinoLedPhy phy(32, 33);
PacketLED led(phy);

PacketLedTransport optical(led);
EspNowTransport radio;

LedDisplay display(optical);
NvsPairStorage storage;

SecurePair pairing(optical, storage, display, display);
SecureLink channel(pairing, radio);

void setup() {
  button.begin();
  led.begin();
  pairing.begin();
  pairing.provision(button);
  radio.begin();
  channel.sync();
}

ดู SecurePair จับคู่ ESP32 ผ่านแสงทำงานจริง

Video ของ Project แสดงแนวคิด LED-to-LED Pairing และการใช้ Pattern กระพริบ เพื่อให้ผู้ใช้ยืนยัน Device ทั้งสองฝั่ง

Project แบบไหนน่าเอาแนวคิด SecurePair ไปต่อ?

Sensor Node + Gateway

Pair Sensor กับ Gateway บนโต๊ะด้วย LED ก่อนนำ Node ไปติดตั้ง แล้วส่งข้อมูลผ่าน ESP-NOW หรือ Transport อื่นที่เหมาะกับระบบ

Device ที่ไม่มีหน้าจอหรือ Keyboard

Device ที่มีเพียง LED และ Button ก็ยังสร้าง Human-verifiable Pairing Flow ได้

Remote Control / Actuator

SecurePair README ยกตัวอย่าง Command สำหรับ Relay, Gate Opener หรือ Lock ที่ต้องการ Authentication และ Replay Protection

Service / Provisioning Interface

PacketLED ยังสามารถใช้ Indicator LED เดิมของ Product เป็น Optical Data Port สำหรับ Configuration หรือ Debug โดยไม่ต้องเพิ่ม Connector แยก

FAQ: SecurePair, PacketLED และ ESP32 Optical Pairing

สรุป: ของที่น่าสนใจไม่ใช่แค่ “LED คุยกันได้” แต่คือการเอาแสงมาเป็น Pairing Channel

สิ่งที่ทำให้ SecurePair น่าสนใจกว่า Demo Optical Communication ทั่วไป คือการเอา Physical Property ของ LED มาผูกเข้ากับ Security Workflow จริง

PacketLED ทำให้ LED ดวงเดียว รับและส่ง Packet ได้

SecurePair นำ Link นั้น ไปใช้แลก Key แล้วให้คนยืนยัน Short Authentication String ก่อนบันทึก Peer

หลังจากนั้น Device ไม่จำเป็นต้องคุยผ่านแสงอีกต่อไป เพราะ Key เดิมสามารถนำไปใช้ กับ SecureLink บน ESP-NOW หรือ Transport อื่นได้

สำหรับ Maker นี่เป็น Project ที่เชื่อมหลายเรื่องเข้าด้วยกัน: Electronics, ADC, Optical Communication, Packet Protocol, ESP-NOW และ Applied Cryptography

เพียงต้องจำไว้ว่า SecurePair ยังอยู่ใน Beta และผู้สร้างเองก็ระบุว่า Protocol ยังต้องการ Independent Review ก่อนที่เราจะตีความว่า เหมาะกับระบบ Security-critical

โปรเจกต์นี้มีทั้ง Optical Link และ Security Protocol แนะนำอ่าน Source ต้นฉบับควบคู่กัน

ถ้าต้องการสร้าง Project จริง ควรอ่านทั้ง SecurePair และ PacketLED เพราะ SecurePair README เน้น Pairing / Encryption ส่วน PacketLED Documentation อธิบาย Physical Layer, Wiring, Timing และ Optical Link โดยละเอียดกว่า

อ่านบทความ Two Microcontrollers Talking, All It Needs Is An LED จาก Hackaday

ดู Source Code และ Documentation ของ SecurePair

อ่าน PacketLED Documentation และ Optical Link Details

อ่าน SecurePair Protocol Specification

อ่าน Security Notes และวิธีรายงาน Vulnerability

ดูวิดีโอ SecurePair: encrypted ESP32 links, paired through light