تنسيق سلك الكابلات

توضّح هذه الصفحة تنسيق Tink السلكي للمفاتيح وإخراج العناصر الأساسية. هذه المستندات مخصّصة لعلماء التشفير الذين يريدون إضافة لغات أخرى إلى Tink، وللمشرفين على مكتبات التشفير الأخرى ذات المستوى العالي الذين يريدون وضعًا متوافقًا مع التنسيق السلكي. وهو غير مخصّص للجمهور العام.

تسلسل مفاتيح Keyset

تستخدم Tink Google protobuf لتسلسل مجموعات المفاتيح.

• مجموعة المفاتيح المتسلسلة الثنائية هي Keyset proto متسلسلة تم تحديدها في tink.proto. سمة KeyData الخاصة بقيمة المفتاح هي بروتوكول تسلسلي لنوع المفتاح المقابل.
• مجموعة المفاتيح المتسلسلة بتنسيق JSON هي مجموعة مفاتيح أولية متسلسلة بتنسيق JSON. يُرجى العِلم أنّ قيمة KeyData لا تزال عبارة عن ثنائي متسلسل.
• مجموعة المفاتيح المشفّرة هي EncryptedKeyset proto متسلسلة محدّدة في tink.proto. يحتوي على مجموعة مفاتيح تسلسلية ثنائية مشفّرة ويحتوي اختياريًا على بعض البيانات الوصفية غير المشفّرة الخاصة بـ KeysetInfo.

بادئة ناتج Tink

تتيح معظم عناصر Tink الأساسية استخدام بادئة إخراج مؤلّفة من 5 بايتات، وتتضمّن ما يلي:

• إصدار البايت الواحد: 0x01
• تلميح المفتاح المكوّن من 4 بايت: هذا هو معرّف المفتاح المستخدَم.

قد تتوافق بعض المفاتيح القديمة أيضًا مع بايت الإصدار 0x00.

يستخدم العنصر الأساسي Prehash بايت الإصدار 0xff، راجِع قيم التجزئة المسبقة الخارجية لـ Mu ML-DSA.

يُرجى العِلم أنّه لم تتم مصادقة هذه البادئات ولا يمكن الاعتماد عليها لأغراض أمنية. تستخدم 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 المسودة الخاصة بـ AES-CBC-HMAC من Mcgrew.

تشفير AEAD الحتمي

تنفِّذ مكتبة Tink RFC 5297 لخوارزمية AES-SIV، ما يضع متجه التهيئة الاصطناعي (SIV) في بداية النص المشفّر. قد تضيف السمة الأساسية بادئة إخراج Tink بحجم 5 بايت.

على الرغم من أنّ RFC 5297 يتيح استخدام قائمة بالبيانات المرتبطة، لا يتيح Tink سوى استخدام بيانات مرتبطة واحدة بالضبط، وهو ما يتوافق مع قائمة تتضمّن عنصرًا واحدًا في RFC 5297. البيانات المرتبطة الفارغة هي قائمة تحتوي على عنصر فارغ واحد، وليست قائمة فارغة.

Streaming AEAD

يمكنك الاطّلاع على AES-CTR HMAC وAES-GCM-HKDF.

التشفير باستخدام مفتاحين

يشفّر التشفير المغلف البيانات باستخدام مفتاح تشفير البيانات DEK باستخدام عناصر AEAD الأساسية في Tink. يعمل التشفير على النحو التالي:

• يتم إنشاء DEK جديد باستخدام نموذج مفتاح (أو مَعلمات مفتاح) معيّن.
• يتم تسلسل DEK إلى سلسلة بايت. تنسيق التسلسل الذي يتيح تسلسل بروتوكول المخزن المؤقت لنوع المفتاح الأوّلي على سبيل المثال، هذه رسالة مخزَّنة بتنسيق تسلسليAesGcmKey من Protocol Buffers تم تحديدها في aes_gcm.proto لمفتاح تشفير البيانات من نوع AES GCM. يمكنك الاطّلاع على تسلسل Protocol Buffers لمعرفة كيفية تسلسل Protocol Buffers.
• يتم تشفير DEK المتسلسل من خلال مقدّم خدمة خارجي (مثل Google Cloud Platform)، إلى encrypted DEK.
• يُستخدَم DEK لتشفير النص العادي مع البيانات المرتبطة به إلى ciphertext. لذلك، يكون ciphertext بالتنسيق نفسه تمامًا الذي يستخدمه العنصر الأساسي AEAD المتوافق مع DEK.

يكون تنسيق ناتج التشفير المزدوج على النحو التالي:

encrypted DEK length || encrypted DEK || ciphertext

يبلغ حجم encrypted DEK length 4 بايت، ويخزّن طول encrypted DEK كعدد صحيح كبير الترتيب من 32 بت.

التحكم في الوصول للوسائط

تتّبع مكتبة Tink معايير RFC ذات الصلة. قد تضيف العناصر الأساسية بادئة تتألف من 5 بايتات إلى العلامة.

مجموعة وظائف عشوائية

تتّبع مكتبة Tink معايير RFC ذات الصلة. يُرجى العِلم أنّ نوع مفتاح PRF يختلف عن نوع مفتاح MAC الخاص بالخوارزمية نفسها من خلال عدم تضمين طول الإخراج. لا تضيف مفاتيح مجموعة PRF أبدًا بادئة ناتج Tink. يضمن ذلك أن يكون الناتج عبارة عن دالة عشوائية زائفة.

التشفير المختلط

في ما يلي تنسيق البيانات العام في التشفير المختلط في 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
  • التنسيق الذي يحدّده AEAD HPKE المستخدَم

آلية KEM المستندة إلى خوارزمية Diffie-Hellman باستخدام المنحنى X25519

بالنسبة إلى X25519 DHKEM، تكون القيمة 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_ss للنقطة المشتركة. يتم بعد ذلك ضبط مفتاح AEAD على:

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

حيث encapsulated_key هو ناتج KEM الكامل بالبايت.

التوقيعات الرقمية

تتّبع Tink معايير RFC ذات الصلة. قد تضيف العناصر الأساسية بادئة تتألف من 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 غير صالحة).

يساعد ذلك في منع هجمات تغيير التوقيع، والتي غالبًا ما تؤثر في أنظمة العملات المشفّرة.

قيم التجزئة المسبقة لـ Mu ML-DSA الخارجية

يحوّل العنصر الأساسي Prehash الرسالة إلى قيمة prehash، ثم يوقّع العنصر الأساسي SignPrehash على هذه القيمة. بالنسبة إلى ML-DSA في وضع External Mu كما هو موضّح في RFC 9881، تبلغ قيمة prehash 69 بايت مع التصميم التالي:

0xff || key_id (4 bytes, big-endian) || mu (64 bytes)

• mu هو ممثل رسالة ML-DSA، ويتم حسابه على النحو التالي: SHAKE256(tr || 0x00 || 0x00 || message, 64)، حيث tr هو تجزئة 64 بايت للمفتاح العام، و0x00 الأولى هي فاصل نطاق FIPS 204 لـ ML-DSA الخالص، و0x00 الثانية هي طول سلسلة السياق (الفارغة). بما أنّ tr مشتق من المفتاح العام، فإنّ mu مرتبط تشفيرًا بهذا المفتاح، مع أنّ التحقّق من الربط يتطلّب الرسالة الأصلية.
• البادئة المكوّنة من 5 بايت هي إطار Tink، وليست جزءًا من mu. ويربط قيمة prehash بمفتاح معيّن، لكي يعرف SignPrehash المفتاح الذي سيتم التوقيع به، ويمكنه رفض قيمة prehash التي ليس لديه مفتاح لها. البادئة هي بيانات وصفية عادية ولا ترتبط بأي شيء مشفّر، إذ يمكن لأي شخص إعادة كتابتها.

ترفض عملية التوقيع أي إدخال لا يبلغ حجمه 69 بايت بالضبط، أو لا يبدأ بـ 0xff، أو لا يتطابق معرّف مفتاحه مع مفتاح مفعّل في مجموعة مفاتيحه.