בדף הזה מתוארים הפורמטים של Tink להעברת מפתחות ופלט פרימיטיבי. המסמכים מיועדים למומחים בקריפטוגרפיה שרוצים להוסיף שפות נוספות ל-Tink, ולמנהלי ספריות קריפטוגרפיות אחרות ברמה גבוהה שרוצים מצב תואם לחיבור לרשת. הוא לא מיועד לקהל הרחב.
סריאליזציה של קבוצת מפתחות
ב-Tink נעשה שימוש ב-Google protobuf כדי לסדר בסדרת רצפים את קבוצות המפתחות.
- קבוצת מפתחות בסריאליזציה בינארית היא פרוטו של קבוצת מפתחות בסריאליזציה שמוגדרת ב-tink.proto. מאפיין הערך KeyData של מפתח הוא פרוטו מסונכרן של סוג המפתח המתאים.
- קבוצת מפתחות בסריאליזציה של JSON היא קבוצת מפתחות מסוג proto בסריאליזציה בפורמט JSON. חשוב לזכור שהערך של KeyData הוא עדיין פרוטו מסונכרן בינארי.
- קבוצת מפתחות מוצפנת היא פרוטוקול EncryptedKeyset בסריאליזציה שמוגדר ב-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 בביטים, שמיוצג כמספר שלם ללא סימן ב-big-endian של 64 סיביות. הסכימה הזו של HMAC מבוססת על הטיוטה של McGrew ל-AES-CBC-HMAC.
AEAD דטרמיניסטי
ב-Tink מוטמע RFC 5297 עבור AES-SIV, ומיקום וקטור האתחול הסינתטי (SIV) הוא בתחילת הטקסט המוצפן. הרכיב הפרימיטיבי עשוי להוסיף קידומת של 5 בייטים של פלט Tink.
ב-RFC 5297 יש תמיכה ברשימת נתונים משויכים, אבל ב-Tink יש תמיכה רק בנתון משויך אחד, שתואם לרשימה עם רכיב אחד ב-RFC 5297. נתונים משויכים ריקים הם רשימה עם אלמנט ריק אחד, ולא רשימה ריקה.
סטרימינג של AEAD
אפשר לעיין במאמרים AES-CTR HMAC ו-AES-GCM-HKDF.
הצפנת מעטפה
בהצפנת מעטפת, הנתונים מוצפנים באמצעות מפתח להצפנת נתונים DEK באמצעות רכיבי AEAD של Tink. כך פועלת ההצפנה:
- המערכת יוצרת
DEKחדש באמצעות תבנית מפתח נתונה (או פרמטרים של מפתח). - ה-
DEKעובר סריאליזציה למחרוזת בייטים. הפורמט של הסריאליזציה הוא פורמט הסריאליזציה של מאגר הפרוטוקולים של סוג המפתח proto. לדוגמה, זוהי הודעת מאגר נתונים זמני של פרוטוקול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 ביט ב-big-endian.
MAC
Tink פועל בהתאם ל-RFCs המתאימים. פרימיטיבים עשויים להוסיף לתג קידומת של 5 בייטים של פלט Tink.
קבוצת PRF
Tink פועל בהתאם ל-RFCs המתאימים. חשוב לציין שבקבוצת PRF, סוג המפתח שונה מסוג מפתח ה-MAC של אותו אלגוריתם, כי הוא לא כולל את אורך הפלט. מפתחות של קבוצות PRF אף פעם לא מוסיפים קידומת פלט של Tink. כך מוודאים שהפלט הוא אכן PRF.
הצפנה היברידית
הפורמט הכללי של הצפנה היברידית ב-Tink הוא:
prefix || encapsulated_key || encrypted_data
השדה prefix יכול להיות ריק או תחילית פלט של Tink באורך 5 בייטים. כל סוג מפתח מכיל את המידע על מספר הבייטים שצריך לנתח ואת אופן הניתוח של הבייטים האלה מ-encapsulated_key.
HPKE (הצפנה היברידית של מפתח ציבורי)
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 - הפורמט נקבע לפי ה-KEM הספציפי של HPKE שבו נעשה שימוש
encrypted_data- טקסט מוצפן ותג (כלומר,
ciphertext || tagללא ה-IV) - מוגדר כ-
ctב-RFC 9180, סעיף 4 - הפורמט נקבע לפי ה-HPKE AEAD הספציפי שבו נעשה שימוש
- טקסט מוצפן ותג (כלומר,
KEM מבוסס-Diffie-Hellman מסוג X25519
ב-DHKEM של X25519, הערך enc הוא המפתח הציבורי של השולח מסוג Diffie-Hellman באורך 32 בייטים.
ECIES-AEAD-HKDF
בהטמעה של ECIES-AEAD-HKDF ב-Tink, הערך encapsulated_key הוא הפלט של מנגנון האנקפסולציה של מפתחות (KEM) והערך encrypted_data הוא הפלט של מנגנון האנקפסולציה של נתונים (DEM).
KEM
בהתאם לסוג המפתח, Tink משתמש בנקודות של עקומה אליפטית דחוסות ולא דחוסות, בהתאם לתקני הקידוד RFC 8422/ANSI.X9-62.2005. בנקודות לא דחוסות, אחרי הביתט 0x04 מופיעות הקואורדינטות x ו-y כמספרים שלמים בגודל קבוע. בקואורדינטות דחוסות, נעשה שימוש בייט 0x02 או 0x03 ובקואורדינטה x כמספר שלם בגודל קבוע. בשדה X25519 נעשה שימוש בהגדרה של RFC 7748 (הקואורדינטה x כמספר שלם בגודל קבוע).
DEM
עבור encrypted_data, Tink משתמשת באותו פורמט כמו ה-AEAD. כולל ציון IV.
הפקת מפתחות
קודם מחשבים את קואורדינטת ה-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 פועל בהתאם ל-RFCs המתאימים. פרימיטיבים עשויים להוסיף תוספת של 5 בייטים של פלט Tink לתג שנוצר.
ECDSA
בהתאם לשדה EcdsaSignatureEncoding במפתח, הפורמט של חתימה ECDSA הוא IEEE P1363 או ASN.1 DER.
הפורמט של החתימה IEEE P1363 הוא r || s, כאשר r ו-s ממולאים באפסים ויש להם את אותו גודל בבייטים כמו הסדר של העקומה. לדוגמה, ב-curve NIST P-256, ה-padding של 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 לא תקינות).
כך אפשר למנוע מתקפות של זיוף חתימות, שמשפיעות לעיתים קרובות על מערכות של מטבעות וירטואליים.