การรับรองความถูกต้องสำหรับเกมที่มีผู้เล่นหลายคนผ่านซ็อกเก็ต


11

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

  • คุณสามารถแนะนำรูปแบบการส่งรหัสผ่านที่ปลอดภัย / ความลับระหว่างการเข้าสู่ระบบได้หรือไม่? (การแลกเปลี่ยนคีย์ Diffie-Hellman?)
  • ฉันจะใช้การเข้ารหัสที่รัดกุมสำหรับแพ็กเก็ตข้อมูลได้อย่างไร (AES 128- บิต? .. หรือรูปแบบใดก็ตามที่โพสต์นี้อ้างถึง "การเข้ารหัสที่แข็งแกร่งกว่าที่คุณจะถอดรหัส")
  • มีรูปแบบดาตาแกรมที่ช่วยให้เซิร์ฟเวอร์เกมแข็งขึ้นเพื่อเล่นซ้ำการโจมตีแพ็คเก็ตข้อมูลที่ไม่ถูกต้องและสิ่งที่คล้ายกันหรือไม่

คำตอบ:


15

คำตอบ

  • SRP - รหัสผ่านระยะไกลที่ปลอดภัย - สิ่งนี้เป็นไปตาม Diffie-Hellman แนวคิดก็คือคุณสามารถทำการตรวจสอบรหัสผ่านร่วมกันโดยไม่ต้องถ่ายโอนรหัสผ่านหรือข้อมูลใด ๆ ที่สามารถนำมาใช้เพื่อรับมา แม้ว่ามันจะเป็นความปลอดภัยมากกว่าลวดที่คุณจะยังคงกัญชาและเกลือรหัสผ่านของคุณเป็นเซิร์ฟเวอร์ของคุณต้องไม่เคยเก็บไว้ในข้อความธรรมดา
  • ข้อได้เปรียบของ SRP คือเมื่อเสร็จสมบูรณ์แล้วก็จะให้คีย์เข้ารหัสที่ต่อรองกับคุณซึ่งผู้โจมตีจะไม่สามารถอนุมานได้เนื่องจากข้อมูลที่คุณถ่ายโอนนั้น ซึ่งหมายความว่าคุณมีอิสระในการใช้อัลกอริทึมการเข้ารหัสแบบสมมาตร (เช่น AES) เมื่อผู้ใช้รับรองความถูกต้องแล้ว
  • สมมติว่าคุณกำลังใช้ UDP ด้วยการใช้งานที่เชื่อถือได้ / สั่งซื้อ (การเชื่อมต่อที่มุ่งเน้น) ที่ด้านบนของมัน: เข้ารหัส playload UDP ทั้งหมด - รวมถึง 'หมายเลขลำดับแพ็กเก็ต' ของคุณ หากระบบของคุณได้รับการออกแบบอย่างถูกต้องระบบจะปฏิเสธข้อความที่เล่นซ้ำโดยอัตโนมัติและผู้บุกรุกจะไม่สามารถเปลี่ยนหมายเลขลำดับของแพ็คเก็ตได้เนื่องจากมีการเข้ารหัส (ดังนั้นการเล่นซ้ำจึงเป็นไปได้ - แต่มันจะถูกเพิกเฉยโดยอัตโนมัติ)

ความคิด

การพิสูจน์ตัวตนของคุณควรปลอดภัยหรือไม่ อย่างแน่นอน อย่าประนีประนอมในเรื่องความปลอดภัยเมื่อมีคำถามเกี่ยวกับรหัสผ่าน ดังนั้นคุณควรจะพิจารณากระสุนแรกในคำตอบของฉัน

ข้อมูลของคุณควรปลอดภัยหรือไม่ เฉพาะในกรณีที่เป็นการซื้อในเกม / การทำธุรกรรมขนาดเล็ก - และทำไมไม่ใช้สิ่งที่ทดลองและเป็นจริงเช่น HTTPS การเข้ารหัสทราฟฟิกเกมของคุณไม่น่าจะเป็นทางออกที่ทำงานได้ด้วยเหตุผลดังต่อไปนี้:

  • มันเป็นความหวาดระแวงที่สมบูรณ์
  • มันจะเพิ่มโอเวอร์เฮดเวลาของ CPU บนเซิร์ฟเวอร์ของคุณเว้นแต่คุณจะซื้อโมดูลการเข้ารหัสฮาร์ดแวร์ (แพง)
  • ไม่สำคัญว่าคุณจะให้ความปลอดภัยแก่ข้อมูลของคุณผ่านสายมากน้อยเพียงใดใครบางคนสามารถขโมยกระบวนการไคลเอนต์และสกัดกั้นข้อความสักครู่ก่อนที่พวกเขาจะถูกเข้ารหัสและส่ง นี้ไม่ได้เป็นเพียงความเป็นไปได้ แต่เพียบไปได้มากขึ้นในขณะที่มันเป็นอย่างมากง่ายต่อการฉีดรหัสเมื่อเทียบกับแพ็คเก็ตที่ขัดขวาง หากคุณกำลังทำสิ่งนี้เพื่อป้องกันการโกงคุณเสียเวลาและเสียสละอย่างเต็มที่
    • ในแง่ของการรักษาความปลอดภัยของรหัสผ่านไม่มีสิ่งใดที่คุณสามารถทำได้เกี่ยวกับระบบที่ถูกแย่งชิงลูกค้าได้กลายเป็นศัตรู Dongizz ของ Blizzards WoW ได้รับการออกแบบมาเพื่อจัดการกับสิ่งนี้ - แต่ฉันไม่แน่ใจว่าปลอดภัยแค่ไหน (โดยเฉพาะถ้าคุณเสียบปลั๊กทิ้งไว้)

กรุณาถ้าคุณกำลังเข้ารหัสเพื่อป้องกันการโกงละทิ้งมัน คุณกำลังจะเกิดขึ้นในระยะสั้น - ฉันให้ข้อมูลแก่คุณในกรณีที่คุณไม่ได้ โปรดจำไว้ว่าคุณสามารถเลือกที่จะเข้ารหัสแพ็กเก็ตด้วยไบต์แรกในแพคเก็ตที่เป็นและตัวบ่งชี้ว่าส่วนที่เหลือจะถูกเข้ารหัสหรือไม่: แม้ว่าอีกครั้งฉันจะติดกับ HTTPS หากคุณต้องการทำสิ่งต่าง ๆ เช่นธุรกรรมบัตรเครดิต HTTPS ออกแบบโดยผู้เชี่ยวชาญ - ไม่เหมือนกับที่คุณหรือฉันออกแบบ

จากทั้งหมดที่กล่าวมา Blizzard ทำการเข้ารหัสปริมาณการใช้งาน WoW ของพวกเขา เหตุผลหลักที่ทำให้เกิดปัญหานี้เนื่องจากมีคนที่น่าจะเป็นมือสมัครเล่นที่สมบูรณ์ตัดสินใจว่าพวกเขาจะลองใช้อัลกอริทึมการเข้ารหัสที่บ้าน นี้แพนออกมาได้ดีจริงๆ แม้ว่าคุณจะใช้อัลกอริทึมมาตรฐานอุตสาหกรรมมีโอกาสที่ดีที่ใครบางคนจะทำวิศวกรรมย้อนกลับรหัสของคุณและจำลองมัน - เมื่อลูกค้าป้อนรหัสผ่านของพวกเขาจะไม่มีการบอกว่ามีการเชื่อมต่อระบบที่ไม่สนับสนุน


2
+1 สำหรับการบอกว่าการเข้ารหัสแพ็กเก็ตข้อมูลเพื่อป้องกันการโกงนั้นไม่มีประโยชน์ OP: จะยืนยันทุกอย่างที่คุณได้รับจากลูกค้าที่ใช้ตรวจสอบสติตรวจสอบอีกครั้งหากการกระทำของลูกค้าที่มีการร้องขอเป็นไปได้ช่วงการตรวจสอบอาวุธความเร็วในการเคลื่อนที่ ฯลฯ แต่ไม่ต้องเสียเวลาการรักษาความปลอดภัยของลูกค้าในขณะที่มันจะได้รับ hacked ถ้า เกมของคุณมีค่า บริษัท MMO บางแห่งทำการเข้ารหัสและทำให้ยุ่งเหยิงลูกค้า / โปรโตคอล แต่ไม่ใช่เพื่อป้องกันการโกง แต่จะทำให้ยากขึ้นเช่นผู้สร้างบอตเพื่อให้ได้ผลลัพธ์ที่ดีและแม้จะทำโดยทีมผู้เชี่ยวชาญเฉพาะทาง
Gilead

1
เล่นลิ้นเล็ก ๆ น้อย ๆ เกี่ยวกับคำตอบที่สามของคุณ: เพียงแค่การเข้ารหัสแพ็กเก็ตที่อาจจะไม่เพียงพอที่จะป้องกันการเจาะตั้งแต่รูปแบบการเข้ารหัสจำนวนมากอย่างน้อยค่อนข้างอ่อน เพื่อความสมบูรณ์ของข้อความป้องกันคุณจะต้องทั้งMACหรือโหมดการเข้ารหัสรับรองความถูกต้อง
Ilmari Karonen

+1 ขอบคุณสำหรับคำตอบที่สมบูรณ์มาก กำลังมองหาการนำ SRP ไปใช้ในตอนนี้ คุณแนะนำอะไรเกี่ยวกับฟังก์ชั่นแฮชที่ใช้สำหรับรหัสผ่าน MD5? โปรโตคอล OTR (Off the Record) เป็นอย่างไรสำหรับกรณีการใช้งาน? มันจะทำงานได้ดีสำหรับ auth / crypto แทนที่จะเป็น SRP หรือไม่ ในกรณีที่ฉันใช้ SRP ฉันจะต้องใช้หนึ่งในโหมด "การเข้ารหัสที่รับรองความถูกต้อง" ต่อไปนี้หรือไม่ (OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC และ GCM)
Robinicks

1
@ Jenko ใช้อัลกอริทึมตระกูล SHA (น่าจะเป็น SHA1) - คุณควรหลีกเลี่ยง MD5 ในวันนี้ OTR ไม่ใช่สิ่งที่คุณควรดู - ไม่ได้ออกแบบมาให้ปลอดภัย / คลุมเครือ (อันที่จริงมันถูกออกแบบมาเพื่อให้ใครบางคนสามารถปลอมแปลงแพ็คเก็ตได้ง่ายขึ้น ) มันออกแบบมาสำหรับการส่งข้อความโต้ตอบแบบทันที ไม่จำเป็นต้องใช้โหมดเหล่านั้นเพียงใช้ SRP: เมื่อคุณมีคีย์สมมาตรซึ่งต่อรองร่วมกันเพียงแค่สามารถเข้ารหัสบางสิ่งได้ก็รับประกันว่าเพียงพอที่คุณจะพูดคุยกับบุคคลที่สามที่ถูกต้อง อีกครั้งอ่านสองย่อหน้าสุดท้ายของฉันอีกครั้ง
Jonathan Dickinson

1
ที่จริงแล้วฉันมีข้อเสนอแนะที่ดียิ่งขึ้น: ใช้DTLSที่มีอยู่มากกว่าการใช้UDPและไม่พยายามที่จะม้วนของคุณเอง มันจะช่วยให้คุณประหยัดเวลาและมีจำนวนมากของรายละเอียดเล็ก ๆ แต่สำคัญที่เป็นเรื่องง่ายที่จะได้รับผิดถ้าคุณพยายามที่จะออกแบบชั้นเข้ารหัสดาต้าของคุณเอง
Ilmari Karonen

2

ฉันคิดว่าความคิดเห็นสุดท้ายของฉันต่อคำตอบที่ยอดเยี่ยมของโจนาธานนั้นคุ้มค่าที่จะขยายไปสู่คำตอบของมันเอง:

หากคุณไม่มีประสบการณ์ crypto มากมายคุณไม่ควรพยายามออกแบบเลเยอร์การเข้ารหัสของคุณเองหากคุณสามารถหลีกเลี่ยงได้ ถ้าคุณทำมีจำนวนมากประสบการณ์การเข้ารหัสลับที่คุณควรรู้ดีกว่าการออกแบบชั้นการเข้ารหัสของคุณเองถ้าคุณสามารถหลีกเลี่ยงได้

ให้ลองหาไลบรารี crypto ที่เป็นมาตรฐานและผ่านการทดสอบแล้วว่ามีสิ่งที่คุณต้องการ ในกรณีของคุณฉันขอแนะนำGnuTLSซึ่งตาม Wikipediaให้ทั้งการตรวจสอบความถูกต้องTLS-SRP ( RFC 5054 ) และการสื่อสาร UDP ที่ปลอดภัยด้วยDTLS ( RFC 6347 ) อดีตดูแลการเข้าสู่ระบบในขณะที่หลังปกป้องช่องทางที่ปลอดภัยที่เกิดขึ้นจากทั้งสองจึงแอบฟังและการโจมตีที่ใช้งานและยังสามารถปกป้องคุณจากการโจมตี replay


ฉันใช้ TCP นี่เป็นเกมประเภทที่แตกต่างกันมากสำหรับลูกค้าเฉพาะราย เช่นเดียวกับการพนัน / การพนันข้อมูลทั้งหมดที่สามารถใช้ในการจี้กระบวนการเพิ่มโอกาสของการสูญเสียที่ไม่จำเป็นโดยบ้าน เราจำเป็นต้องรักษาข้อมูลให้ปลอดภัยอย่างยิ่งเพราะข้อมูลเป็นเงินในกรณีนี้
Robinicks

ตกลงถ้าคุณใช้ TCP ก็จะยิ่งง่ายขึ้น: คุณสามารถใช้ TLS 1.2 ปกติแทน DTLS ซึ่งให้ตัวเลือกเพิ่มเติมให้คุณเลือก ฉันยังคงแนะนำห้องสมุด GnuTLS อยู่
Ilmari Karonen

ฉันจะทำการวิจัยเล็กน้อยและดูว่าฉันสามารถอ้างถึงซอร์สโค้ด TLS ทั้งในฝั่งไคลเอ็นต์และเซิร์ฟเวอร์และยึดโปรโตคอลของฉันเกี่ยวกับสิ่งที่มันทำ สิ่งนี้จะแข็งแรงเพียงพอหรือไม่ มันเป็นเพียงแค่การเข้ารหัสแพ็คเก็ตที่มีตัวเลข / โหมดถูกต้องหรือไม่
Robinicks

ไม่มีโปรโตคอล TLSมากกว่านั้นอีกเล็กน้อย นี่คือเหตุผลที่คุณต้องการใช้ไลบรารี่มาตรฐานที่ใช้มันแทนที่จะนำไปใช้เอง
Ilmari Karonen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.