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

توضّح هذه الصفحة تنسيق 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.

يُرجى العِلم أنّ هذه البادئة غير مصادَق عليها ولا يمكن الاعتماد عليها لأغراض الأمان. تستخدمها 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. يمكنك الاطّلاع على تسلسل البيانات المنظّمة لمعرفة كيفية تسلسل البيانات المنظّمة.
  • يتم تشفير 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 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، تبلغ قيمة التجزئة المسبقة 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، أو لا يتطابق رقم تعريف المفتاح الخاص به مع مفتاح مفعّل في مجموعة المفاتيح.