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

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

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

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

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

بادئة نتائج الترابط

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

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

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

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

AEAD

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

prefix || IV || ciphertext || tag

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

AES-CTR-HMAC

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

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

حيث يكون bitlen(AD) هو طول AD بوحدات البت ويتم تمثيله كـ 64 بت كبير الحجم عدد صحيح غير موقَّع. ويتّبع نظام HMAC هذا مسودة AES-CBC-HMAC من Mcgrew.

عينة عينية مقتنعة

تطبّق 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 بت كبير.

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

يتبع Tink طلبات التعليقات (RFC) المقابلة. قد تضيف الأساسيات إخراج Tink بحجم 5 بايت. بادئة بالعلامة.

مجموعة PRF

يتبع Tink طلبات التعليقات (RFC) المقابلة. لاحظ أنه بالنسبة إلى تعيين PRF، يختلف نوع المفتاح من نوع مفتاح MAC للخوارزمية نفسها من خلال عدم تضمين طول الإخراج. لا تضيف مفاتيح PRF Set بادئة Tink أجريتها أبدًا. يضمن ذلك أن يكون الإخراج خاصية PRF

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

في ما يلي التنسيق العام للأسلاك لتشفير Tink الهجين:

prefix || encapsulated_key || encrypted_data

تكون السمة prefix إما فارغة أو بادئة خط 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
    • التنسيق الذي يتم تحديده بواسطة HPKE KEM المحدد المستخدم
  • encrypted_data
    • النص المُشفر والعلامة (أي ciphertext || tag بدون IV)
    • تم تحديدها على أنّها ct في الفقرة 4 من معيار RFC 9180
    • التنسيق الذي تم تحديده من خلال HPKE AEAD المحدّد والمستخدَم
KEM مستند إلى Diffie-Hellman

بالنسبة إلى أجهزة 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 كعدد صحيح بحجم ثابت).

مارك ألماني

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

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