เมื่อคุณทำงานกับสภาพแวดล้อมที่มีข้อจำกัดอย่างมาก มันอาจจะมีส่วนร่วมมากกว่าที่คุณจะได้รับจากการฟังคนแปลกหน้าบน stackexchange คุณอาจต้องปฏิบัติตามมาตรฐานการเข้ารหัส CAN บัสที่มีอยู่ (เขียนโดยผู้เชี่ยวชาญ) หรือขอนักพัฒนามืออาชีพ - ข้อกังวลไปไกลกว่า "ฉันจะใช้ AES ได้อย่างไร"
ฉันจะอธิบายบางประเด็นที่ชัดเจน:
เป้าหมายด้านความปลอดภัยคืออะไร? คนที่ฟังบน CAN บัสไม่สามารถอ่านข้อความได้หรือไม่? หรือเป็นเพียงเพื่อให้แน่ใจว่าข้อความที่ได้รับมาจากผู้ส่งที่ได้รับอนุญาต ตัวอย่างเช่น มีคนอื่นบน CAN บัสไม่สามารถแทรกคำสั่งของตนเองได้ ไม่ว่าจะเป็นคำสั่งแบบสุ่ม (การโจมตีของ DOS) คำสั่งที่เลือก หรือออกคำสั่งที่ถูกต้องก่อนหน้านี้ใหม่หรือไม่ มีคนไม่สามารถแก้ไขคำสั่งระหว่างการบินได้ (ซึ่งอาจเป็นไปได้ หากพวกเขาสามารถรับข้อความรหัสได้ ด้วยวิธีใดวิธีหนึ่งจะป้องกันไม่ให้ผู้รับรับข้อความรหัสดั้งเดิม แล้วออกข้อความรหัสที่แก้ไขแล้วใหม่)
คุณระบุว่าข้อความเข้ารหัสต้องเป็น 8 ไบต์ - ข้อความธรรมดาที่สอดคล้องกันคือ 8 ไบต์ด้วยหรือไม่ ปัญหาคือว่ามีคนสามารถใส่ข้อความเข้ารหัสขนาด 8 ไบต์ และมันจะถอดรหัสเป็นข้อความธรรมดาที่ถูกต้อง
การใช้ AES ถือว่าผู้ส่งและผู้รับใช้รหัสลับร่วมกัน นี้เป็นจริงหรือไม่ คีย์ถูกแชร์อย่างไร? มีการเตรียมล่วงหน้าที่โรงงานหรือเวลาติดตั้งหรือไม่? หรือมีการเจรจาอย่างใด (และหากมี รายละเอียดเป็นอย่างไร)?
ฉันคิดว่าผู้ส่งและผู้รับไม่รับประกันว่าจะยังคง "ซิงค์กัน"; นั่นคือ ผู้รับอาจพลาดข้อความที่ถูกต้องจากผู้ส่ง ฉันยังสันนิษฐานว่าระบบจะต้อง 'พยายามอย่างเต็มที่'; นั่นคือ การที่ระบบปฏิเสธข้อความที่ถูกต้องนั้นเป็นเรื่องที่รับไม่ได้ (เช่น คุณไม่ต้องการเพิกเฉยต่อข้อความเหยียบเบรกว่า "ฉันเพิ่งถูกกด" เพียงเพราะระบบเข้ารหัสเพิ่งเข้าสู่สถานะที่ไม่ถูกต้อง) หากสมมติฐานนี้ไม่เป็นความจริง มีเทคนิคที่เป็นประโยชน์บางอย่างที่เป็นไปได้
ตอนนี้ จากคำตอบที่เป็นไปได้ข้างต้น สัญชาตญาณแรกของฉันสำหรับโหมดการเข้ารหัสคือการใช้รูปแบบที่รักษาการเข้ารหัส เช่น FF1 (ซึ่งใช้ AES เพื่อเข้ารหัสข้อความความยาวตามอำเภอใจ เช่น 64 บิต) อย่างไรก็ตาม FF1 มีราคาแพงในการคำนวณ (ใช้การประเมิน AES ประมาณ 10 ครั้งเพื่อเข้ารหัส/ถอดรหัสข้อความ 64 บิต) และดีที่สุดเป็นเพียงส่วนเล็กๆ ของโซลูชันทั้งหมด