עיצוב מפתחות לייבוא

במאמר הזה מוסבר איך לעצב את המפתחות כך שניתן יהיה לייבא אותם על ידי Cloud KMS כגרסאות חדשות של מפתחות.

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

פורמטים נתמכים של מפתחות

• מפתחות סימטריים להצפנה: מפתחות סימטריים מיובאים צריכים להיות בגודל 16 בייט (במקרה של הצפנה סימטרית גולמית בלבד) או בגודל 32 בייט של נתונים בינאריים, ואסור שהם יהיו מקודדים. אם המפתח שלכם מקודד בפורמט הקסדצימלי או בפורמט base64, אתם צריכים לפענח אותו לפני שתנסו לייבא אותו.
• מפתחות סימטריים לחתימה (מפתחות MAC): מפתחות חתימה של HMAC שיובאו צריכים להיות באורך ששווה לאורך הפלט של פונקציית הגיבוב הקריפטוגרפית שבה נעשה שימוש (לדוגמה, מפתחות HMAC-SHA256 צריכים להיות באורך של 32 בייט), ואסור שהם יהיו מקודדים. אם המפתח שלכם מקודד בפורמט הקסדצימלי או בפורמט base64, אתם צריכים לפענח אותו לפני שתנסו לייבא אותו.
• מפתחות אסימטריים להצפנה או לחתימה: מפתחות אסימטריים מיובאים חייבים להיות בפורמט PKCS #8 ומקודדים ב-DER. הפורמט PCKS #8 מוגדר ב-RFC 5208. קידוד DER מוגדר באיגוד הטלקומוניקציה הבינלאומי X.680. מפתחות אסימטריים חייבים להשתמש באחת מהקומבינציות של אורך ואלגוריתם שנתמכות על ידי Cloud KMS.

חשוב: האקספוננט הציבורי של מפתח RSA חייב להיות 65,537 ומעלה. זו דרישה של תקן חתימה דיגיטלית (DSS) שמצוינת בקטע Criteria for IFC Key Pairs (קריטריונים לזוגות מפתחות של IFC) של FIPS PUB 186-4, Section B.3.1

אחרי שיוצרים מפתח, אי אפשר לשנות חלק מהמאפיינים שלו, כמו האורך. במקרים כאלה, אי אפשר לייבא את המפתח ל-Cloud KMS.

בדיקת מפתח סימטרי

משתמשים בפקודה wc כדי לבדוק את האורך של מפתח סימטרי.

wc -c /path/to/unwrapped-key

• אי אפשר לייבא מפתח הצפנה סימטרי באורך שונה מ-32.

• אורך מפתחות חתימה סימטריים (מפתחות MAC) צריך להיות שווה לאורך הפלט של פונקציית הגיבוב הקריפטוגרפית שבה נעשה שימוש (לדוגמה, האורך של מפתחות HMAC-SHA256 צריך להיות 32 בייט).

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

file /path/to/unwrapped-key

• אם הפלט הוא data, המפתח בפורמט הנכון לייבוא.

• אם הפלט הוא ASCII text, משתמשים בפקודה cat כדי להציג את תוכן הקובץ.

  • אם מדובר במחרוזת של אותיות ומספרים שמסתיימת בסימן =, יכול להיות שהיא בקידוד Base64. משתמשים בפקודה base64 (או Base64.exe ב-Windows) כדי לפענח אותו. הנה דוגמה למפתח בקידוד Base64:

    THzArjassB+giKeNeT1Zr74OgV24t+Ep+37Ec6ojB3Y=
    

  • אם הוא מכיל שורה אחת או יותר של מספרים הקסדצימליים, יכול להיות שהוא מקודד בפורמט הקסדצימלי. משתמשים בפקודה xxd (או בפקודת Format-Hex PowerShell ב-Windows) כדי לפענח אותו. הנה דוגמה למפתח בקידוד הקסדצימלי:

    00000000: 4c7c c0ae 36ac b01f a088 a78d 793d 59af  L|..6.......y=Y.
    00000010: be0e 815d b8b7 e129 fb7e c473 aa23 0776  ...]...).~.s.#.v
    

  • אם הוא מכיל טקסט אחר, יכול להיות שהוא לא מפתח סימטרי תקין.

עיצוב מפתחות אסימטריים

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

1. משתמשים בפקודה file כדי לבדוק את הפורמט של מפתח.

   file /path/to/unwrapped-key
   

   • אם הפלט הוא PEM, המפתח הוא בפורמט PEM. אם הוא ASCII text, סביר להניח שהוא בפורמט PEM. בכל מקרה, מריצים את הפקודה הבאה כדי להמיר אותו לפורמט PCKS#8 DER:

     openssl pkcs8 -topk8 -nocrypt -inform PEM -outform DER \
         -in /path/to/asymmetric-key-pem \
         -out /path/to/formatted-key
     

   • אם הפלט הוא data, סביר להניח שהמפתח הוא בפורמט DER, אבל יכול להיות שהוא לא בפורמט PKCS #8. מריצים את הפקודה הבאה כדי לוודא שהמפתח בפורמט הנכון. לפקודה אין השפעה אם המפתח כבר בפורמט הנכון. במקרה כזה, אפשר להשתמש בפקודה diff כדי לוודא שקובץ הקלט וקובץ הפלט זהים.

     openssl pkcs8 -topk8 -nocrypt -inform DER -outform DER \
         -in /path/to/asymmetric-key-der \
         -out /path/to/formatted-key
     

פתרון בעיות

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

המאמרים הבאים

• המשך אל ייבוא גרסת מפתח
• מידע נוסף על ייבוא מפתחות