אימות הקושחה של מכונה וירטואלית מסוג Confidential VM

הקושחה של כל המכונות הווירטואליות הסודיות היא UEFI, והיא מבוססת על פרויקט Open Virtual Machine Firmware. הקושחה מנוהלת על ידי Google כדי לשמור על האבטחה, הביצועים והיציבות.

קושחה בניהול Google גם מבטיחה עקביות של הערכים שמאוחסנים ברישומי המדידה ב-Root of Trust של מופע Confidential VM. הפעולה הזו עוזרת למנוע חסימה של עומסי עבודה של Confidential Computing על ידי אימות (attestation) כשמתבצע עדכון של הקושחה של מופע Confidential VM.

כדי לוודא שמכונת ה-VM הסודית שלכם פועלת על קושחה מקורית שמנוהלת על ידי Google, אתם יכולים לבצע את המשימות הבאות:

  • אחזור אישור הפעלה שחתום על ידי Google במופעי מכונות וירטואליות סודיות עם AMD SEV-SNP או Intel TDX מופעלים. אישור השקה מכיל מדידות חתומות ומחושבות מראש שקשורות לקושחה.

  • מאמתים את אישור ההשקה על ידי השוואה למדידות ספציפיות לארכיטקטורה.

  • מוודאים שהקובץ הבינארי של UEFI נתמך על ידי Google ולא בוצעו בו שינויים.

בנוסף לאימות מרחוק, אפשר לכלול אימות של קושחה כחלק ממדיניות האבטחה שקובעת אם למופע של Confidential VM תהיה גישה למשאבים מוגנים.

אחזור אישורי השקה

אתם יכולים לאחזר המלצות להשקה באמצעות הכלים של Google או באמצעות כלים משלכם.

אחזור המלצות להשקה באמצעות כלים של Google

כדי לאחזר אישור הפעלה ממופע של מכונה וירטואלית חסויה של AMD SEV-SNP או Intel TDX באמצעות כלי Google:

  1. משתמשים ב-SSH כדי להתחבר למכונה הווירטואלית הסודית.

  2. כדי לאחזר דוח אימות ואישורים משויכים, אפשר להשתמש ב-Go-TPM-Tools (AMD SEV-SNP או Intel TDX) או ב-SEV Guest (AMD SEV-SNP).

  3. משתמשים ב-gcetcbendorsement כדי לחלץ את אישור ה-UEFI מהאימות ולאחסן אותו בקובץ. לאחר מכן תוכלו לוודא שההמלצה מקושרת ל-Google ושהמדידה בדוח האימות היא אחת מהמדידות החתומות.

אחזור המלצות להשקה באמצעות כלים משלכם

כדי לאחזר אישור השקה באמצעות כלים משלכם, צריך לפעול לפי ההוראות הבאות.

AMD SEV-SNP

  1. שולחים בקשה מורחבת לאורח למעבד המאובטח של AMD כדי לאחזר דוח אימות.

  2. חילוץ המדידה של הדוח ב-384 ביט שמאוחסנת בהיסט 90h. מידע נוסף זמין במאמר SEV Secure Nested Paging Firmware ABI Specification, פרק 7.3, טבלה 22.

  3. כדי להוריד אישור השקה של הפניה מסודרת מקטגוריית Cloud Storage הבאה, משתמשים במדידה של 384 ביט:

    gs://gce_tcb_integrity/ovmf_x64_csm/sevsnp/384_BIT_MEASUREMENT.binarypb

  4. מפענחים את קובץ BINARYPB באמצעות כלי כמו protoc, באמצעות הגדרת ההודעה VMLaunchEndorsement:

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

מיקומים חלופיים להשקת אישור

יכול להיות שאישור ההשקה יהיה זמין גם בטבלת GUID במנגנון העברת האישורים של AMD SEV-SNP. ה-GUID שלו הוא:

9f4116cd-c503-4f5a-8f6f-fb68882f4ce2

טבלת ה-GUID מתועדת במפרט של בלוק תקשורת בין אורח ל-Hypervisor של AMD, בקטע 'בקשת אורח מורחבת של SNP'.

יכול להיות שיהיו גם הפניות למיקומים מקומיים ומרוחקים של אישור ההפעלה ביומן האירועים של לקוח המחשב של Trusted Computing Group, שמופיע באירוע SP800-155 כפי שמתואר ב-TCG PC Client Platform Firmware Profile Specification Version 1.06 Revision 52.

Intel TDX

  1. יוצרים רשומה של דוח configfs-tsm:

    name=/sys/kernel/config/tsm/report/report0
mkdir "${name}"
cat "${your_nonce_file}" > "${name}/inblob"
cat "${name}/outblob" > "${your_quote_destination}"

  2. מחלקים את המדידה של תחום האמון (TD) של הציטוט, באורך 384 ביט, שמאוחסנת בהיסט b8h (במודול TDX 1.5). מידע נוסף זמין במאמר בנושא ספריית הצעות המחיר של TDX DCAP.

  3. כדי להוריד אישור השקה של הפניה מסודרת מקטגוריית Cloud Storage הבאה, משתמשים במדידה של 384 ביט:

    gs://gce_tcb_integrity/ovmf_x64_csm/tdx/384_BIT_MEASUREMENT.binarypb

  4. מפענחים את אישור ההשקה באמצעות כלי כמו protoc, באמצעות הגדרת ההודעה VMLaunchEndorsement:

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

דוגמה להמלצה על אפליקציה

דוגמה לאישור השקה:

VMLaunchEndorsement:
serialized_uefi_golden: "SERIALIZED_BYTES"
signature: "LAUNCH_ENDORSEMENT_SIGNATURE_BYTES"

מדידות זהב של UEFI

השדה serialized_uefi_golden מכיל גרסה סדרתית של כמה ערכים, כפי שמוגדר על ידי מאגר אחסון לפרוטוקולים הבא:

message VMGoldenMeasurement {
  google.protobuf.Timestamp timestamp = 1;

  // The changelist number this UEFI was built from.
  uint64 cl_spec = 2;

  // DER format certificate of the key that signed this document.
  bytes cert = 4;

  // SHA-384 digest of the UEFI binary without TEE-specifics about launch.
  bytes digest = 5;

  // A sequence of PEM-encoded certificates of keys used in cert in Root ...
  // final intermediate order. The last certificate will have a signed cert.
  bytes ca_bundle = 6;

  VMSevSnp sev_snp = 7;

  VMTdx tdx = 8;
}

השדה VMSevSnp בהודעה VMGoldenMeasurement מוגדר על ידי מאגר אחסון לפרוטוקולים הבא:

message VMSevSnp {
  // The Google-reported security version number of this UEFI on SEV-SNP.
  uint32 svn = 1;

  // Expected MEASUREMENT report field values given [key]-many VMSAs at launch.
  map<uint32, bytes> measurements = 2; // bytes size 48

  // A UUID that Google uses for its CVM UEFIs
  bytes family_id = 3; // size 16

  // A UUID to name this specific release of the UEFI image. This is randomly
  // generated with each build.
  bytes image_id = 4; // size 16

  // The launch policy that verifiers should expect with this UEFI.
  uint64 policy = 5;

  // Optional. PEM-encoded certs for Identity..Author..Root. If a singleton,
  // only an Id-key is used.
  bytes ca_bundle = 6;
}

השדה VMTdx בהודעה VMGoldenMeasurement מוגדר על ידי מאגר אחסון לפרוטוקולים הבא:

message VMTdx {
  message Measurement {
    // The amount of RAM in GiB provided to the VM. This is relevant to the
    // construction of the measured TDHOB page that includes memory region
    // resource attributes.
    uint32 ram_gib = 1;
    // If true, EFI_UNACCEPTED_MEMORY not presented to guest.
    // All memory is accepted by the firmware. Relevant to the TDHOB page
    // since the resource attribute will include
    // EFI_RESOURCE_ATTRIBUTE_NEEDS_EARLY_ACCEPT.
    bool early_accept = 2;
    // The SHA-384 digest of the measurement operations for the VM at launch.
    bytes mrtd = 3;
  }
  // The Google-reported security version number of this UEFI on TDX.
  uint32 svn = 1;

  // Expected MRTD report field values given legal configurations.
  repeated Measurement measurements = 2;
}

כדי לפתוח את הערכים האלה ולפענח אותם מהתג serialized_uefi_golden field באמצעות כלים משלכם, צריך לבצע את השלבים הבאים:

  1. מקצים הודעה חדשה VMGoldenMeasurement.

  2. ביטול ה-marshal של serialized_uefi_golden בהודעה.

אפשר גם להשתמש בפקודה gcetcbendorsement inspect .

אימות של המלצות להשקה

אחרי שמאחזרים אישור השקה, מאמתים את החתימה שלו ומשלבים את המדידות שלו במדיניות האבטחה שלכם, במקומות המתאימים.

אימות חתימה של אישור השקה

כדי לאמת את החתימה של אישור ההפעלה, צריך לכלול את תעודת מפתח הבסיס של בסיס המחשוב המהימן של Compute Engine Confidential Computing בעוגני האמון.

השדה cert של VMGoldenMeasurement באישור ההפעלה מכיל אישור X.509v3 בקידוד DER של המפתח הציבורי של מפתח חתימת האישור. האישור חתום על ידי מפתח הבסיס.

אתם יכולים להשתמש ב-gcetcbendorsement כדי לראות אילו פקודות של openssl צריך להריץ כדי לאמת את החתימה. לדוגמה, אם מריצים את הפקודה הבאה:

gcetcbendorsement verify --show LAUNCH_ENDORSEMENT_FILENAME.binarypb

אמורה להתקבל תגובה שדומה לדוגמה הבאה:

openssl verify -CAfile <(openssl x509 -outform pem -in <(curl https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt)) \
    <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert) \
    && \
    openssl pkeyutl -verify -pkeyopt rsa_padding_mode:pss \
        -pkeyopt rsa_pss_saltlen:32 -pkeyopt digest:sha256 -pkeyopt rsa_mgf1_md:sha256 -pubin \
        -inkey <(openssl x509 -pubkey -nocert -outform pem -in <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert)) \
        -sigfile <(gcetcbendorsement inspect signature "LAUNCH_ENDORSEMENT_FILENAME.binarypb") -keyform PEM \
        -in <(openssl dgst -sha256 -binary <(gcetcbendorsement inspect payload "LAUNCH_ENDORSEMENT_FILENAME.binarypb")

אם אתם מעדיפים להשתמש בכלים משלכם, אתם יכולים להחליף את הפקודות gcetcbendorsement inspect שמופיעות בתשובה בלוגיקה משלכם לחילוץ מאגר פרוטוקולים של השדות שצוינו בהודעה VMGoldenMeasurement שעברה דה-סריאליזציה.

אימות המדידות של אישור ההשקה

קוד לדוגמה שמראה איך יוצרים אישור השקה זמין במאגר gce-tcb-verifier ב-GitHub. אתם יכולים להשתמש בנתונים האלה כדי להבין איך Google הפיקה את המדידות מ-UEFI, וכדי לשלב מדידות רלוונטיות במדיניות האבטחה שלכם.

לדוגמה, אפשר לבדוק שהקושחה חתומה על ידי ספק הקושחה, ולהשוות את המדידות הספציפיות לארכיטקטורה לערכים מחושבים מראש וחתומים שמופיעים בהודעה VMLaunchEndorsement.

למרות שהקושחה הווירטואלית של Compute Engine משודרגת באיפוס, הערך של PCR0 לא משתנה. לכן, הערך svn של הקושחה בחתימה של המדידה עשוי להיות שונה מהערך EV_S_CRTM_VERSION שנמדד ב-PCR0, והאירוע EV_POST_CODE בתקציר של blob הקושחה מדלג.

אימות של קובץ בינארי של UEFI במכונה וירטואלית מסוג Confidential VM

  1. מאישור השקה, פורקים את הערך serialized_uefi_golden לתוך VMGoldenMeasurement. דוגמאות אפשר לראות בהטמעה ב-Go או בהידור protoc של endorsement.proto בשפה אחרת שתומכת ב-protocol buffers.

  2. מאחזרים את ערך ה-digest מ-VMGoldenMeasurement. זהו תקציר SHA-384 של קובץ ה-UEFI הבינארי שעליו פועלת מכונת ה-VM הסודית.

  3. משתמשים ב-SHA-384 digest כדי להוריד את הקובץ הבינארי של הקושחה מקטגוריית Cloud Storage הבאה:

    gs://gce_tcb_integrity/ovmf_x64_csm/UEFI_BINARY_DIGEST.fd

  4. אם זו כתובת URL תקינה והקושחה מורידה, מבצעים גיבוב SHA-384 בבינארי של הקושחה. אם הוא זהה לערך ה-digest מהמדידה המדויקת, הקושחה שפועלת במופע של המכונה הווירטואלית הסודית פועלת ללא שינויים.