פורמט חוט Tink

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

סריאליזציה של ערכת מפתחות

Tink משתמש ב-Google protobuf כדי לערוך סדרה של מפתחות המפתח.

• ערכת מפתחות בינארית עם רצף בינארי היא פרוטו של מערך מפתחות בהסדרה המוגדר ב-tink.proto. מאפיין הערך של KeyData של מפתח הוא אב טורי של סוג המפתח התואם.
• ערכת מפתחות טורית של JSON היא פרוטו של מערך מפתחות בפורמט JSON. שימו לב שהערך של KeyData הוא עדיין אב סדרה בינארי.
• קבוצת מפתחות מוצפנת היא פרוטו EncryptedKeyst שעבר סדרה שמוגדרת ב-tink.proto. הוא מכיל קבוצת מפתחות בינארית מוצפנת עם רצף, ויש גם מטא-נתונים לא מוצפנים של KeysetInfo.

קידומת של פלט Tink

רוב פרימיטיבים Tink תומכים בקידומת פלט של 5 בייט שכוללת:

• גרסת בייט אחד: 0x01
• 4 בייטים של רמז למפתח: זהו מזהה המפתח של המפתח שבו נעשה שימוש.

חלק מהמפתחות מדור קודם תומכים גם בגרסת הבייט 0x00.

חשוב לשים לב שהקידומת הזו לא מאומתת ואי אפשר לסמוך עליה לצורכי אבטחה. ב-Tink משתמש בו כרמז כדי לזרז את הפענוח או האימות.

AEAD

באופן כללי, פורמט Tink מעצב טקסט מוצפן של AEAD באופן הבא:

prefix || IV || ciphertext || tag

אלא אם צוין אחרת ב-RFC התואם. השדה prefix ריק או עם תחילית פלט Tink בגודל 5 בייט.

AES-CTR-HMAC

ב-AES-CTR-HMAC, Tink מחשבת את ה-MAC עם הנתונים המשויכים (AD) באופן הבא:

AD || IV || ciphertext || bitlen(AD)

כאשר bitlen(AD) הוא האורך של AD בביטים, שמיוצגים כמספר שלם ללא חתימה ב-64 סיביות. סכמת ה-HMAC פועלת לפי הטיוטה של AES-CBC-HMAC ב-Mcgrew.

AEAD דטרמיני

ב-Tink מטמיעה את RFC 5297 ל-AES-SIV, ווקטור האתחול הסינתטי (SIV) מופיע בתחילת הטקסט המוצפן. יכול להיות שהמערכת תוסיף תחילית פלט Tink בגודל 5 בייט.

RFC 5297 תומך ברשימה של נתונים משויכים, אבל ב-Tink תומך רק בנתונים משויכים אחד שתואמים לרשימה שיש בה רכיב אחד ב-RFC 5297. נתונים משויכים ריקים הם רשימה שיש בה רכיב ריק אחד ולא רשימה ריקה.

סטרימינג בפורמט AEAD

אפשר לקרוא מידע נוסף ב-AES-CTR HMAC וב-AES-GCM-HKDF.

הצפנת מעטפת

הצפנת הנתונים מתבצעת באמצעות מפתח להצפנת נתונים DEK באמצעות פרימיטיבים מסוג AEAD של Tink. ההצפנה פועלת כך:

• נוצר DEK חדש באמצעות תבנית מפתח נתונה (או פרמטרים של מפתח).
• השדה DEK עובר סריאלית למחרוזת בייט. פורמט העריכה בסדרה, של העורך בהמשכים של מאגר הנתונים הזמני של סוג המפתח. לדוגמה, זוהי הודעה סריאלית של פרוטוקול AesGcmKey למאגר, שמוגדרת ב-aes_gcm.proto ל-DEK מסוג מפתח AES GCM. במאמר יצירת סדרה של מאגר אחסון לפרוטוקולים מוסבר איך ליצור סדרה של מאגר אחסון לפרוטוקולים.
• ה-DEK שבסדרה מוצפנת על ידי ספק חיצוני (למשל GCP), ל-encrypted DEK.
• DEK משמש להצפנת הטקסט ללא הצפנה עם הנתונים המשויכים אליו ב-ciphertext. ל-ciphertext יש בדיוק אותו פורמט של פרימיטיב AEAD שתואם ל-DEK.

פורמט הפלט של הצפנת המעטפה הוא:

encrypted DEK length || encrypted DEK || ciphertext

ה-encrypted DEK length הוא 4 בייט, המאחסן את אורך ה-encrypted DEK כמספר שלם גדול-אנדי ב-32 סיביות.

MAC

סימן ה-Tink עוקב אחר ה-RFC המתאימים. אפשר להוסיף לתג תחילית פלט Tink בגודל 5 בייט.

הוגדר PRF

סימן ה-Tink עוקב אחר ה-RFC המתאימים. שימו לב שבהגדרת PRF סוג המפתח שונה מסוג מפתח ה-MAC באותו אלגוריתם, בכך שהוא לא כולל את אורך הפלט. מפתחות להגדרת PRF אף פעם לא מוסיפים תחילית פלט Tink. כך אפשר להבטיח שהפלט יהיה למעשה PRF.

הצפנה היברידית

פורמט הכבל הכללי להצפנה היברידית Tink הוא:

prefix || encapsulated_key || encrypted_data

השדה prefix ריק או עם תחילית פלט Tink בגודל 5 בייט. כל סוג מפתח מכיל מידע על מספר הבייטים שצריך לנתח ואופן הניתוח של הבייטים האלה מ-encapsulated_key.

HPKE (Hybrid Public Key Encryption)

ה-Tink תואם לתקן HPKE שהוגדר ב-RFC 9180. סטים של אלגוריתמים להצפנה מסוג HPKE כוללים את שלושת הרכיבים הפשוטים הבאים.

• מנגנון אנקפסולציה של מפתחות (KEM)
• פונקציית נגזרת מפתח (KDF)
• הצפנה מאומתת עם נתונים משויכים (AEAD)

תקן HPKE לא מגדיר פורמט חוטים כללי ב-RFC 9180, סעיף 10. בהטמעת ה-HPKE של Tink נעשה שימוש בערכים encapsulated_key ו-encrypted_data הבאים.

• encapsulated_key
  • מפתח ציבורי סידורי של השולח
  • מוגדר כ-enc ב-RFC 9180, סעיף 4.1
  • הפורמט נקבע לפי ה-HPKE KEM הספציפי שבו נעשה שימוש
• encrypted_data
  • מידע מוצפן ותג (כלומר, ciphertext || tag ללא IV)
  • מוגדר כ-ct ב-RFC 9180, סעיף 4
  • הפורמט נקבע לפי ה-HPKE AEAD הספציפי שבו נעשה שימוש

KEM שמבוסס על X25519 Diffie-Hellman

ב-X25519 DHKEM, הערך enc הוא מפתח Diffie-Hellman ציבורי בגודל 32 בייטים של השולח.

ECIES-AEAD-HKDF

בהטמעה של ECIES-AEAD-HKDF של Tink, encapsulated_key הוא הפלט של מנגנון האנקפסולציה של המפתח (KEM) ו-encrypted_data הוא הפלט של מנגנון אנקפסולציה של הנתונים (DEM).

קם

בהתאם לסוג המפתח, ב-Tink משתמשת בנקודות של עקומה אליפטית דחוסה ולא דחוסה, בהתאם לתקני הקידוד RFC 8422/ANSI.X9-62.2005. בנקודות לא דחוסות, אחרי הבייט 0x04 מופיעים המספר x והקואורדינטה y כמספרים שלמים בגודל קבוע. עבור קואורדינטות דחוסות, נעשה שימוש בבייט 0x02 או ב-0x03 וקואורדינטה x כמספר שלם בגודל קבוע. עבור X25519, נעשה שימוש בהגדרה RFC 7748 (קואורדינטה x כמספר שלם בגודל קבוע).

מארק גרמני (DEM)

ב-encrypted_data, הפרמטר Tink משתמש בפורמט זהה לזה של AEAD. כולל ציון עירום.

גזירה של מפתח

תחילה מחושבת קואורדינטת ה-x x_ss של הנקודה המשותפת. לאחר מכן, המפתח ל-AEAD מוגדר בתור:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

encapsulated_key הוא הפלט המלא של ה-KEM כבייטים.

חתימות דיגיטליות

סימן ה-Tink עוקב אחר ה-RFC המתאימים. אפשר להוסיף לתג שנוצר קידומת פלט Tink בגודל 5 בייט.

ECDSA

בהתאם לשדה EcdsaSignatureEncoding שבמפתח, הפורמט של חתימת ECDSA הוא IEEE P1363 או ASN.1 DER.

הפורמט של החתימה IEEE P1363 הוא r || s, עם ערכים ריקים ב-r וב-s, וגודלם בבייטים זהה לגודל העקומה. לדוגמה, עבור עקומת NIST P-256, ערכי r ו-s ריקים ב-32 בייטים.

החתימה של DER מקודדת באמצעות ASN.1:

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

באופן ספציפי, הקידוד הוא:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

ספריית Tink פועלת לפי השיטות המומלצות לאימות חתימה, ומיישמת רק חתימות ECDSA בקידוד DER (חתימות עם קידוד BER חלופיות אינן חוקיות).

כך אפשר למנוע התקפות של חתימה על חתימה על חתימה, שבמקרים רבים משפיעות על מערכות של מטבעות וירטואליים.