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

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

تسلسل مجموعات المفاتيح

يستخدم Tink النموذج الأوّلي من Google لإنشاء تسلسل لمجموعات المفاتيح.

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

بادئة إخراج Tink

تتوافق معظم إصدارات Tink الأساسية مع بادئة إخراج 5 بايت تتألف مما يلي:

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

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

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

AEAD

بشكل عام، يعمل Tink على تنسيق النصوص المشفرة AEAD على النحو التالي:

prefix || IV || ciphertext || tag

ما لم يُذكر خلاف ذلك في طلب RFC المقابل. تكون قيمة prefix إما فارغة أو بادئة إخراج Tink بحجم 5 بايت.

تشفير AES-CTR-HMAC

بالنسبة إلى معيار AES-CTR-HMAC، يحسب Tink عنوان MAC مع البيانات المرتبطة به على النحو التالي:

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 طلبات التعليقات المقابلة لها. قد تضيف الوحدات الأساسية بادئة ناتج Tink بحجم 5 بايت إلى العلامة.

مجموعة PRF

يتبع Tink طلبات التعليقات المقابلة لها. تجدر الإشارة إلى أنّه بالنسبة إلى مجموعة PRF Set، يختلف نوع المفتاح عن نوع مفتاح 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 تنسيق سلك عام في الفقرة 10 من RFC 9180. يستخدم تطبيق HPKE من Tink قيمتَي encapsulated_key وencrypted_data التاليين.

• encapsulated_key
  • المفتاح العام المتسلسل للمُرسِل
  • يتم تحديدها على أنّها enc في الفقرة 4.1 من RFC 9180
  • التنسيق المحدد بواسطة HPKE KEM المحدد المستخدم
• encrypted_data
  • النص المُشفر والعلامة (أي ciphertext || tag بدون رقم IV)
  • يتم تحديدها على أنّها ct في الفقرة 4 من RFC 9180
  • التنسيق المحدد بواسطة HPKE AEAD المحدد المستخدم

X25519 خوارزمية KEM القائمة على ديفي هيلمان

بالنسبة إلى أنظمة X25519 DHKEMs، تكون القيمة 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 كعدد صحيح بحجم ثابت).

مارك ألماني

بالنسبة إلى 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 طلبات التعليقات المقابلة لها. قد تضيف الوحدات الأساسية بادئة ناتج 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 غير صالحة).

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