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

ทำไมฉันถึงใช้ UML

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

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

ในเวลาต่อมา ที่ทำงานอื่น ฉันกำลังเขียนสมุดปกขาวเกี่ยวกับความปลอดภัยพร้อมไดอะแกรมอีกครั้ง ฉันไม่สามารถใช้อนุสัญญาเฉพาะกิจฉบับเดียวกันได้เนื่องจากเป็นทรัพย์สินทางปัญญาของนายจ้างคนก่อนของฉัน นั่นคือตอนที่ฉันหันไปใช้มาตรฐานที่ฉันคุ้นเคยแล้ว นั่นคือ Unified Modeling Language (UML)

UML เป็นชุดเครื่องมือ

ข้อดีอย่างหนึ่งของมาตรฐาน UML คือมีเครื่องมือและไม่ได้กำหนดกฎเกณฑ์ UML ของฉันไม่เข้มงวด บางครั้งฉันใช้องค์ประกอบมาตรฐานในทางที่ไม่ได้มาตรฐาน แต่ไดอะแกรมของฉันสอดคล้องกับสิ่งที่ Martin Fowler อธิบายว่าเป็น “เศษส่วนของ UML ที่มีประโยชน์มากที่สุด”

มาตรฐาน UML เป็นเครื่องมือที่จะช่วยฉันอธิบายการเข้ารหัสของโซลูชัน

สิ่งที่ควรอธิบาย

ฉันอธิบายสิ่งต่อไปนี้ทั้งหมดด้วย UML

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

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

ตัวอย่างข้อกำหนดของผลิตภัณฑ์

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

ลองจินตนาการว่าผลิตภัณฑ์คือ Digital Encabulator for Enterprise (DEE) เวอร์ชัน 1 DEE อาจพร้อมใช้งานสำหรับผู้ใช้ปลายทางบนอุปกรณ์พกพา และบนคอมพิวเตอร์แล็ปท็อปและเดสก์ท็อป ข้อกำหนดด้านความปลอดภัยให้ทำทั้งหมดต่อไปนี้

• ปกป้องข้อมูลที่เหลือด้วยการเข้ารหัสตามรหัสผ่าน ( PBE ) รหัสผ่านจะเป็นค่าลับที่ผู้ใช้ป้อน
• รองรับการเปลี่ยนรหัสผ่านโดยไม่มีการหยุดทำงานของข้อมูลที่มีการป้องกัน
• รองรับการกู้คืนข้อมูลในกรณีที่ผู้ใช้ลืมรหัสผ่าน
• สนับสนุนการตรวจสอบข้อมูลโดยองค์กรโดยที่ผู้ใช้ปลายทางไม่ทราบ
• ใช้หลักปฏิบัติที่รู้จักกันดีและเป็นมาตรฐานสำหรับการเข้ารหัส

• รหัสผ่านถูกกำหนดโดยผู้ใช้แต่ละคนเมื่อพวกเขาติดตั้งแอป
• คีย์รหัสผ่าน (PK) ถูกสร้างขึ้นจากรหัสผ่านโดยกระบวนการ PBKDF2 (Passcode Based Key Derivation Function เวอร์ชัน 2) ด้วยพารามิเตอร์เหล่านี้
  - ฟังก์ชัน pseudorandom รหัสตรวจสอบข้อความแบบแฮช (HMAC)
  - ฟังก์ชันแฮช SHA256
  - ทำซ้ำ 20,000 ครั้ง
• ค่าเกลือของรหัสผ่าน (PS) จะรวมอยู่ในอินพุต PBKDF2 PS จะถูกสร้างขึ้นโดยเครื่องสร้างตัวเลขสุ่มที่ปลอดภัย (RNG)
• ค่า PS จะถูกเก็บไว้ในอุปกรณ์อย่างต่อเนื่อง ไม่มีการจัดเก็บค่า PK และรหัสผ่าน

• ปกป้องข้อมูลแอปพลิเคชันด้วยคีย์การเข้ารหัสข้อมูลระดับกลาง (DEK) DEK จะเป็นค่าสุ่มแบบยาวที่สร้างโดย RNG ที่ปลอดภัย DEK จะมีความยาว 256 บิต เพื่อลดการเดาโดยกำลังดุร้ายในระยะเวลาที่ใช้งานได้จริง
• จัดเก็บ DEK ที่เข้ารหัสโดย PK ในที่เก็บข้อมูลถาวรของอุปกรณ์ อย่าเก็บ DEK ไว้ในที่จัดเก็บแบบถาวร การเข้ารหัสจะใช้อัลกอริทึม AES Key Wrap
• เมื่อผู้ใช้เปลี่ยนรหัสผ่าน ให้เข้ารหัส DEK อีกครั้งด้วยค่า PK ใหม่ (หากไม่มี DEK ข้อมูลแอปพลิเคชันทั้งหมดจะต้องได้รับการเข้ารหัสใหม่เมื่อเปลี่ยนรหัสผ่าน)

• ให้บริการกู้คืนข้อมูล (DRS)
• DRS จะได้รับคำขอตั้งค่า (DRS-SU) เมื่อผู้ใช้ปลายทางสร้าง DEK บนอุปกรณ์ของตน DRS-SU จะรวมตัวระบุผู้ใช้และต้องการการตรวจสอบผู้ใช้นอกแบนด์ ตัวอย่างเช่น โดยการเปลี่ยนเส้นทางผู้ใช้ไปยังผู้ให้บริการข้อมูลประจำตัว (IDP)
• เมื่อ DRS ได้รับ DRS-SU ระบบจะสร้างคู่คีย์สำหรับการเข้ารหัสแบบอสมมาตร คู่คีย์มีคีย์ส่วนตัว (RIK) ที่สร้างและจัดเก็บไว้ในโมดูลความปลอดภัยฮาร์ดแวร์ (HSM) และคีย์สาธารณะ (RUK) ที่สอดคล้องกัน RIK จะมีความยาว 2048 บิต
• DRS ตอบสนองต่อ DRS-SU โดยส่ง RUK กลับมา
• แอพผู้ใช้จัดเก็บ DEK ที่เข้ารหัสโดย RUK ในที่เก็บข้อมูลถาวรของอุปกรณ์ การเข้ารหัสจะใช้อัลกอริทึม RSA พร้อมการเติม PKCS1
• แอปผู้ใช้สามารถส่งคำขอกู้คืน (DRS-RY) ไปยัง DRS DRS-RY จะรวมตัวระบุผู้ใช้และต้องมีการตรวจสอบผู้ใช้ เช่นเดียวกับ DRS-SU และจะรวม DEK ที่เข้ารหัสโดย RUK
• เมื่อ DRS ได้รับ DRS-RY แล้ว DEK จะถูกถอดรหัสโดย RIK ใน HSM DRS ตอบสนองต่อ DRS-RY กับ DEK

• DRS สามารถรับคำขอตรวจสอบ (DRS-AT) DRS-AT จะรวมค่าเดียวกันกับ DRS-RY และเพิ่มตัวระบุผู้ใช้ในการตรวจสอบ ผู้ใช้ตรวจสอบจะต้องได้รับอนุญาต
• การประมวลผลและการตอบสนองของ DRS ต่อ DRS-AT จะเหมือนกับ DRS-RY

ไดอะแกรมนี้แสดงถึงฟังก์ชันการเข้ารหัสพื้นฐานในการใช้งานเป็นไดอะแกรมคลาส UML

แผนภาพแสดงสิ่งต่อไปนี้

Secure Random Number Generator เป็นคลาส ชื่อจะถูกย่อเป็น RNG

• อินสแตนซ์ RNG มีแอตทริบิวต์ความยาว โดยมีค่าเริ่มต้นเป็น 256
• อินสแตนซ์ RNG มีการดำเนินการ getNext โดยไม่มีพารามิเตอร์ที่ส่งคืนบิตความยาว

• อินสแตนซ์การเข้ารหัสมีแอตทริบิวต์ อัลกอริทึม โดยมีค่าเริ่มต้นเป็น AES-GCM (มาตรฐานการเข้ารหัสขั้นสูงในโหมด Galois/Counter)
• อินสแตนซ์การเข้ารหัสมีการดำเนินการ เข้ารหัส ซึ่งใช้สองพารามิเตอร์ คีย์และข้อความธรรมดา และส่งกลับ Ciphertext ไม่มีรายละเอียดเกี่ยวกับประเภทข้อมูล
• อินสแตนซ์ Cipher มีการดำเนินการ ถอดรหัส ซึ่งใช้พารามิเตอร์สองตัว คีย์และ Ciphertext และส่งกลับข้อความธรรมดา ไม่มีรายละเอียดเกี่ยวกับประเภทข้อมูล

ตัวอย่างไดอะแกรมการปรับใช้

ไดอะแกรมนี้แสดงถึงการจัดเก็บและการป้องกันทรัพยากรการเข้ารหัสในการใช้งานเป็นไดอะแกรมการปรับใช้ UML

ขอโทษแทรก: ไดอะแกรมเบี่ยงเบนจากมาตรฐาน UML ด้วยวิธีต่อไปนี้

• อาร์ติแฟกต์ เช่น ข้อมูลแอปพลิเคชัน จะแสดงเป็นรูปสี่เหลี่ยมผืนผ้าโดยไม่มีตัวทำเครื่องหมายเอกสาร
  เครื่องหมายเอกสารดูเหมือนไม่จำเป็นในมาตรฐาน จากรูปสี่เหลี่ยมแบนๆ นั้นชัดเจนอยู่แล้วว่า Application Data ไม่ใช่สภาพแวดล้อมการดำเนินการ
• ออบเจ็กต์ เช่น อินสแตนซ์ RNG จะแสดงในไดอะแกรมการปรับใช้
  ลักษณะที่ใช้ที่นี่ สี่เหลี่ยมผืนผ้าที่มีมุมสี่เหลี่ยมและข้อความที่ขีดเส้นใต้ นำมาจากมาตรฐานไดอะแกรมวัตถุ UML
  การวาดไดอะแกรมอ็อบเจกต์แยกต่างหากด้วยอินสแตนซ์เดียวกัน แต่ไม่มีบริบทที่ปรับใช้จะทำให้ผู้อ่านต้องดูไดอะแกรมเพิ่มเติม
• ป้ายกำกับการเชื่อมต่อไม่แสดงการสื่อสารอย่างแน่นอน แต่จะแสดงชื่อพารามิเตอร์และความสัมพันธ์แทน
• อินสแตนซ์ Asymmetric Cipher แสดงในสภาพแวดล้อม Application Run-Time Memory ถูกต้องสำหรับการเข้ารหัส แต่ไม่ถูกต้องสำหรับการถอดรหัส
  ซึ่งอาจแก้ไขได้โดยการขยายไดอะแกรมเพื่อแสดงสภาพแวดล้อมหรือเอกสารแยกต่างหากสำหรับคำขอตั้งค่า DRS และคำขอกู้คืน DRS

• ข้อมูลนี้ถูกจัดเก็บอย่างต่อเนื่องโดยแอปพลิเคชัน
  - ปล.
  - DEK เข้ารหัสโดย PK
  - ข้อมูลแอปพลิเคชันที่เข้ารหัส
  - DEK เข้ารหัสโดย RUK
• ไม่มีข้อมูลอื่นใดถูกจัดเก็บถาวรโดยแอปพลิเคชัน
• RIK ถูกจัดเก็บไว้ใน HSM ภายใน DRS
• RUK สร้างขึ้นโดย DRS แต่ไม่ได้เก็บไว้ที่นั่น
• DEK ถูกเข้ารหัสโดยสองคีย์ที่แตกต่างกัน RUK และ PK สำหรับการเข้ารหัส PK จะใช้อัลกอริทึม AES-KW (Advanced Encryption Standard Key Wrap) แทน AES-GCM เริ่มต้น
• PS เป็นค่าสุ่มของความยาวเริ่มต้น 256 RIK และ RUK ขึ้นอยู่กับค่าสุ่มของความยาวที่ระบุ 2048

• ข้อมูลแอปพลิเคชันสามารถรับได้จากที่เก็บข้อมูลถาวรเฉพาะเมื่อได้รับ DEK
• สามารถรับ DEK ได้จากที่เก็บข้อมูลถาวรหากทราบรหัสผ่าน PS อยู่ในที่เก็บข้อมูลถาวร และสามารถรับ PK ได้โดยการเรียกใช้ KDF บนรหัสผ่านและ PS
• นอกจากนี้ยังสามารถรับ DEK ได้จากที่เก็บข้อมูลถาวร หาก RIK สามารถเข้าถึงได้ DEK ที่เข้ารหัสโดย RUK จะถูกเก็บไว้อย่างต่อเนื่อง และ RIK สามารถถอดรหัสได้ แผนภาพไม่ได้แสดงว่า DEK ที่เข้ารหัสโดย RUK จะต้องถูกส่งไปยัง DRS เพื่อดำเนินการถอดรหัส

ตัวอย่างแผนภาพกิจกรรม

ไดอะแกรมนี้แสดงถึงการประมวลผลสำหรับการตั้งค่ารหัสผ่านเป็นไดอะแกรมกิจกรรม UML

ใช้องค์ประกอบมาตรฐานต่อไปนี้

• การดำเนินการ เช่น การหาค่าคีย์ จะมีมุมมน
• โหนดออบเจกต์ที่มีมุมสี่เหลี่ยมถูกใช้เพื่อแสดงทรัพยากรการเข้ารหัส เช่น คีย์และค่าเกลือ
• พิน สี่เหลี่ยมเล็กๆ พร้อมป้ายข้อความ ระบุพารามิเตอร์ของการดำเนินการ พินจะใช้ในกรณีที่มีพารามิเตอร์มากกว่าหนึ่งตัวเท่านั้น
  - พารามิเตอร์อินพุตสำหรับกระบวนการเข้ารหัส () มีพินเนื่องจากมีสองคีย์และข้อความธรรมดา
  - ผลลัพธ์ของกระบวนการ encrypt() มีพารามิเตอร์เพียงตัวเดียว นั่นคือ ciphertext ดังนั้นจึงไม่มีพิน
• แถบหนาแสดงถึงการเริ่มต้นและสิ้นสุดของการประมวลผลอิสระ ตัวอย่างเช่น RNG getNext() เพื่อสร้าง PS นั้นไม่ขึ้นอยู่กับ Passcode ซึ่งเป็นพารามิเตอร์ในการประมวลผล KDF นี่อาจไม่ใช่มาตรฐานเสียทีเดียว แต่หลีกเลี่ยงการมี 2 โฟลว์จากทรัพยากรหนึ่งๆ ซึ่งไม่ใช่มาตรฐานอย่างแน่นอน

1. การประมวลผลจะเริ่มขึ้นเมื่อป้อนรหัสผ่านแล้ว
2. ตัวสร้างตัวเลขสุ่มที่ปลอดภัย (RNG) รันด้วยความยาวเริ่มต้น ดังที่แสดงในไดอะแกรมคลาส เอาต์พุตคือรหัสผ่านเกลือ (PS) ซึ่งจัดเก็บอย่างต่อเนื่อง
3. ฟังก์ชันการสืบทอดคีย์ถูกเรียกใช้โดยมีรหัสผ่านเป็นความลับ ค่า PS เป็นเกลือ และอัลกอริทึมเริ่มต้นและจำนวนการวนซ้ำ ดังที่แสดงในแผนภาพคลาส เอาต์พุตคือรหัสรหัสผ่าน (PK) ซึ่งไม่ได้เก็บไว้อย่างต่อเนื่อง
4. RNG อื่นรันด้วยความยาวเริ่มต้น ดังที่แสดงในไดอะแกรมคลาส เอาต์พุตคือคีย์การเข้ารหัสข้อมูล (DEK) ซึ่งไม่ได้จัดเก็บอย่างต่อเนื่อง
5. กระบวนการเข้ารหัสรหัสจะทำงานโดยมี PK เป็นคีย์ DEK เป็นข้อความธรรมดา และอัลกอริทึม AES-KW เอาต์พุตจะถูกเก็บไว้อย่างต่อเนื่อง

• ตั้งค่าการกู้คืนข้อมูล
• เปลี่ยนรหัสผ่าน
• เปิดแอปซึ่งจะรวมถึงการดึงคีย์การเข้ารหัสข้อมูล การดึงข้อมูลอาจมาจากที่เก็บข้อมูลถาวร โดยสร้างรหัสรหัสผ่านใหม่จากรหัสผ่านที่ป้อนโดยผู้ใช้ หรือจากบริการกู้คืนข้อมูล
• เก็บข้อมูลแอปพลิเคชัน

ตัวอย่างข้างต้นแสดงให้เห็นว่าสามารถใช้ไดอะแกรม UML เพื่ออธิบายการเข้ารหัสได้ สามารถใช้ไดอะแกรม UML ประเภทต่างๆ เพื่ออธิบายแง่มุมต่างๆ

• แผนภาพคลาสแสดงมาตรฐานการเข้ารหัสและพารามิเตอร์ที่ใช้
• ไดอะแกรมการปรับใช้แสดงตำแหน่งที่เก็บทรัพยากร หากจัดเก็บไว้ และทรัพยากรใดได้รับการปกป้องโดยคีย์ใด
• แผนภาพกิจกรรมแสดงลำดับการประมวลผล โหนดวัตถุแสดงทรัพยากรที่เกี่ยวข้องในการประมวลผล

สำหรับตัวอย่างคำอธิบายการเข้ารหัสของโซลูชันจริง โปรดดูเอกสารไวท์เปเปอร์ที่เผยแพร่ที่นี่
developer.vmware.com/…/MobileApplicationManagement.pdf
(ไดอะแกรม UML อยู่ในส่วน Workspace ONE Encryption of Data at Rest ภายใต้หัวข้อ Passcode-Based Encryption Diagrams)

ไดอะแกรมในบทความนี้และในเอกสารไวท์เปเปอร์วาดด้วย เครื่องมือ Diagrams.netหรือที่เรียกว่าเครื่องมือ Draw.io

สำหรับความเป็นมาเกี่ยวกับมาตรฐาน Unified Modeling Language (UML) โปรดดูที่https://uml.orgเว็บไซต์และหนังสือ UML Distilled Third Edition โดย Martin Fowler

สำหรับข้อมูลอ้างอิงเกี่ยวกับมาตรฐานและข้อกำหนดในการเข้ารหัส โปรดดูหนังสือ Serious Cryptography โดย Jean-Philippe Aumasson