שימוש ב-CNG Provider וב-SignTool כדי לחתום על ארטיפקטים של Windows

במדריך הזה מוסבר איך ליצור מפתח Cloud HSM לחתימה על Microsoft Authenticode באמצעות פלאגין שמתממשק עם שירותים חיצוניים CNG ו-SignTool.

גרסה של המדריך הזה שמבוססת על Terraform זמינה במאגר GitHub של kms-solutions.

תרחישים לדוגמה

תהליך העבודה שמתואר במסמך הזה עוזר לטפל בצרכי האבטחה הבאים של הארגון:

  • חתימת קושחה באמצעות מפתח פרטי שמוגן על ידי HSM ברמה 3 של FIPS140-2.
  • חתימה על פריטי מידע שנוצרו בתהליך פיתוח (Artifact) של Windows באמצעות הכלי הרגיל SignTool של Windows.

לפני שמתחילים

כדי להשלים את המדריך הזה, תצטרכו:

  • מחשב Windows עם הארטיפקטים שרוצים לחתום עליהם.
  • הגרסה האחרונה של ספק CNG של Cloud KMS, שאפשר להתקין במחשב Windows באמצעות קובץ ההתקנה ‎ .msi שכלול.
  • Cloud Shell או מחשב Linux משלכם, כדי ליצור בקשת חתימה על אישור או אישור. במחשב הזה, משלימים את ההגדרה שמפורטת במאמר הגדרת OpenSSL, כדי להוריד ולהגדיר את ספריית PKCS#11 שלנו.

אם עוד לא הפעלתם את הפקודה gcloud auth application-default login, חשוב לעשות זאת.

אם עדיין לא עשיתם זאת, הורידו את Windows SDK העדכני ביותר במחשב Windows, שכולל את SignTool.

הגדרות אישיות

יצירת מפתח חתימה שמתארח ב-Cloud KMS

באמצעות Cloud Shell או המחשב שלכם, יוצרים אוסף מפתחות של Cloud KMS בפרויקט Google Cloud באמצעות הפקודה הבאה:

gcloud kms keyrings create "KEY_RING" --location "LOCATION"

לאחר מכן, יוצרים מפתח לחתימה בחומרה של Cloud KMS‏ EC-P256-SHA256 בפרויקטGoogle Cloud ובאוסף המפתחות שיצרתם:

gcloud kms keys create "KEY_NAME" --keyring "KEY_RING" \
  --project "PROJECT_ID" --location "LOCATION" \
  --purpose "asymmetric-signing" --default-algorithm "ec-sign-p256-sha256" \
  --protection-level "hsm"

הורדת אישור ה-HSM

אישור HSM הוא הוכחה לכך שהמפתח נמצא ב-HSM. יכול להיות שרשות האישורים (CA) תדרוש את ההוכחה הזו כדי להנפיק אישור אימות מורחב (EV).

כדי להוריד את אישור ה-HSM שמשויך למפתח Cloud KMS:

  1. נכנסים לדף Key Management במסוף Google Cloud .

    כניסה אל Key Management

  2. בוחרים את אוסף המפתחות שמכיל את המפתח שרוצים לאמת, ואז בוחרים את המפתח.

  3. לוחצים על עוד לצד גרסת המפתח שרוצים לאמת, ואז לוחצים על אימות האישור.

  4. בתיבת הדו-שיח Verify attestation (אימות אישור), לוחצים על Download attestation bundle (הורדת חבילת אישורים). קובץ ZIP יורד למחשב ומכיל את שרשראות האישורים והאימות.

הוראות מלאות לאימות האישור שהורד זמינות במאמר בנושא ניתוח האישור.

יצירת אישור בחתימה עצמית באמצעות OpenSSL

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

באמצעות Cloud Shell או המחשב שלכם, יוצרים אישור בחתימה עצמית עם מפתח החתימה שמתארח ב-Cloud KMS. אפשר להשתמש ב-OpenSSL כדי להשתמש ב-URI של PKCS #11 במקום בנתיב קובץ, ולזהות את המפתח לפי התווית שלו. בספריית Cloud KMS PKCS #11, התווית של המפתח שווה לשם ה-CryptoKey.

openssl req -new -x509 -days 3650 -subj '/CN=test/' -sha256 -engine pkcs11 \
  -keyform engine -key pkcs11:object=KEY_NAME > ca.cert

אם הפקודה הזו נכשלת, יכול להיות שהאילוץ PKCS11_MODULE_PATH הוגדר בצורה שגויה, או שאין לכם את ההרשאות הנכונות לשימוש במפתח החתימה של Cloud KMS.

עכשיו אמור להיות לכם אישור שנראה כך:

-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----

מעתיקים את האישור למחשב Windows כדי שאפשר יהיה להשתמש בו עם SignTool כדי לחתום על הארטיפקטים.

יצירת בקשת חתימה על אישור חדשה

אפשר ליצור בקשת חתימה על אישור (CSR) למפתח חתימה ב-Cloud HSM. צריך לבצע את השלבים האלה אם רשות האישורים דורשת CSR כדי ליצור אישור חדש לחתימת קוד.

מריצים את הפקודה הבאה באמצעות Cloud Shell או המכונה שלכם:

openssl req -new -subj '/CN=CERTIFICATE_NAME/' DIGEST_FLAG \
  -engine pkcs11 -keyform engine \
  -key pkcs11:id=KEY_ID > REQUEST_NAME.csr

מחליפים את מה שכתוב בשדות הבאים:

  • CERTIFICATE_NAME: שם לאישור שרוצים ליצור.
  • DIGEST_FLAG: דגל שמציין את סוג התקציר. משתמשים ב--sha256, ב--sha384 או ב--sha512 בהתאם לאלגוריתם של המפתח.
  • KEY_ID: מזהה המשאב המלא של גרסת מפתח חתימה אסימטרי, לדוגמה, projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1.
  • REQUEST_NAME: שם לבקשת חתימת האישור.

חשוב להשתמש באפשרויות הנכונות של -sigopt לסוג המפתח שבו אתם משתמשים.

אי אפשר להשתמש ב-OpenSSL עם מזהה אובייקט שארוך מ-100 תווים. צריך להשתמש בשמות קצרים של KeyRing ו-CryptoKey, או להשתמש ב-pkcs11:object=KEY_NAME במקום זאת. למידע נוסף על מגבלת מזהי האובייקטים של OpenSSL, אפשר לעיין בבעיה שקשורה לכך ב-GitHub.

אחרי שיש לכם את ה-CSR, אתם יכולים לספק אותו לרשות האישורים (CA) כדי לקבל את אישור החתימה. משתמשים באישור שסופק על ידי רשות האישורים בקטע הבא.

חתימה על פריט מידע שנוצר בתהליך פיתוח (Artifact) באמצעות SignTool

אחרי שיצרתם אישור (בחתימה עצמית או שהתקבל מרשות אישורים) והעתקתם אותו למחשב Windows, אתם יכולים להשתמש בו כדי לחתום על ארטיפקט של Windows.

משתמשים ב-SignTool כדי לחתום על הארטיפקטים באמצעות מפתח Cloud KMS והאישור שלכם.

"PATH_TO_SIGNTOOL.EXE" sign ^
  /v /debug /fd sha256 /t http://timestamp.digicert.com ^
  /f PATH_TO_CA.CERT ^
  /csp "Google Cloud KMS Provider" ^
  /kc projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1 ^
  PATH_TO_ARTIFACT_TO_SIGN

מחליפים את מה שכתוב בשדות הבאים:

  • PATH_TO_SIGNTOOL.EXE: הנתיב אל signtool.exe (לדוגמה, C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.19041.0\\x64\\signtool.exe).
  • PATH_TO_CA.CERT: הנתיב לאישור ca.cert.
  • PATH_TO_ARTIFACT_TO_SIGN: הנתיב לארטיפקט שרוצים לחתום עליו.

הסבר מפורט על כל אפשרות של פקודה ועל פורמטים נתמכים של קובצי פריטי מידע שנוצר בתהליך פיתוח (Artifacts) זמין במסמכים הרשמיים של SignTool.