المفتاح الخاص في الفاتورة الإلكترونية

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

هذه المقالة موجَّهة للمطوّرين وفِرَق التقنية الذين يبنون أو يدمجون نظام فوترة متوافقًا مع هيئة الزكاة والضريبة والجمارك (ZATCA). نركّز هنا على المفتاح الخاص وحده: دوره في التوقيع، لماذا يجب أن يبقى سرًّا مطلقًا، كيف تحميه، وماذا يحدث إذا تسرّب. أما المفتاح العام ودوره في التحقق فله مقال مستقل، وآلية التوقيع الرقمي بتفاصيلها لها مرجعها التقني الخاص. نكتفي هنا بالإشارة إليهما عند الحاجة.

ما المفتاح الخاص ولماذا يهمّ في الفوترة الإلكترونية

المفتاح الخاص (Private Key) نصفٌ من زوج مفاتيح غير متماثل (Asymmetric Key Pair). النصف الآخر هو المفتاح العام (Public Key). يُولَّد الزوجان معًا في لحظة واحدة، ويرتبطان رياضيًا بحيث ما يوقّعه المفتاح الخاص لا يتحقق منه إلا المفتاح العام المقابل له، والعكس غير ممكن.

الفرق الجوهري بسيط: المفتاح العام يُوزَّع على الجميع، والمفتاح الخاص يبقى عند صاحبه فقط. هذا التقسيم هو أساس التوقيع الرقمي. عندما يوقّع نظامك فاتورة بالمفتاح الخاص، يستطيع أي طرف يملك المفتاح العام أن يؤكد أن الفاتورة صدرت من نظامك تحديدًا، وأنها لم تتغير بعد التوقيع.

في الفوترة الإلكترونية، تستخدم الهيئة منحنى التشفير الإهليلجي (Elliptic Curve Cryptography). المفتاح الخاص في هذه الحالة عدد صحيح كبير عشوائي على منحنى secp256k1. صِغره النسبي مقارنة بمفاتيح RSA لا يقلّل قوّته: مفتاح إهليلجي بطول 256 بت يوازي في المتانة مفتاح RSA بطول 3072 بت تقريبًا، مع توقيع أسرع وحجم أصغر يناسب رمز الاستجابة السريعة (QR) على الفاتورة.

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

لماذا منحنى إهليلجي وليس RSA

اختيار التشفير الإهليلجي في الفوترة الإلكترونية ليس اعتباطًا. الفاتورة المبسّطة تحمل توقيعها داخل رمز الاستجابة السريعة، ومساحة هذا الرمز محدودة. توقيع ECDSA على منحنى 256 بت يبلغ نحو 64 بايت فقط، بينما توقيع RSA المكافئ له في المتانة يبلغ نحو 384 بايت. الفرق هائل عندما تحاول حشر التوقيع والشهادة في رمز يقرأه هاتف المشتري في ثانية.

إضافة إلى الحجم، عملية التوقيع نفسها أسرع على المنحنى الإهليلجي عند مستويات الأمان العالية. نظام يصدر آلاف الفواتير يوميًا يستفيد من كل جزء من الثانية يوفّره التوقيع الأخفّ. هذه الموازنة بين المتانة والحجم والسرعة هي ما دفع المعايير الحديثة، ومنها مواصفة الهيئة، إلى تبنّي المنحنى الإهليلجي.

دورة حياة المفتاح الخاص في المنظومة

المفتاح الخاص ومعرّف الختم التشفيري CSID

لا يعمل المفتاح الخاص بمعزل عن الهيئة. عند ربط نظامك بمنصة فاتورة، يولّد جهازك زوج المفاتيح محليًا، ثم يرسل طلب توقيع شهادة (Certificate Signing Request) يحوي المفتاح العام فقط. تردّ الهيئة بشهادة رقمية تُعرف بمعرّف الختم التشفيري (CSID).

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

تتعامل المنظومة مع نوعين من الشهادات. الأول شهادة الامتثال (Compliance CSID) وتُستخدم في بيئة الاختبار أثناء مرحلة التهيئة. الثاني شهادة الإنتاج (Production CSID) وتُستخدم لتوقيع الفواتير الفعلية. لكل شهادة مفتاحها الخاص المرتبط بها، ويجب ألا تخلط بينهما.

هذا الجدول يلخّص القاعدة الذهبية: حماية الفوترة الإلكترونية كلها تتلخص في حماية المفتاح الخاص. كل شيء آخر مصمَّم ليكون علنيًا.

أين يقع المفتاح الخاص في مسار الربط

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

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

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

كيف يوقّع المفتاح الخاص الفاتورة خطوة بخطوة

دور المفتاح الخاص الأساسي هو إنتاج الختم التشفيري للفاتورة. لا يوقّع المفتاح الفاتورة كاملة بنصّها الطويل، بل يوقّع بصمة مختصرة منها تُعرف بقيمة التجزئة (Hash). تُحسب البصمة بخوارزمية SHA-256 التي تحوّل أي مدخل مهما طال إلى قيمة ثابتة الطول. للتفاصيل، راجع مقال خوارزمية SHA-256 في الفاتورة الإلكترونية.

تجري عملية التوقيع على هذا النحو:

1. يولّد نظامك تمثيل الفاتورة بصيغة XML وفق معيار UBL 2.1.
2. يحسب بصمة SHA-256 للأجزاء المحددة في مواصفة الهيئة.
3. يوقّع البصمة بالمفتاح الخاص باستخدام خوارزمية ECDSA على منحنى secp256k1.
4. يضمّن التوقيع الناتج داخل الفاتورة، ويدرج المفتاح العام والشهادة في رمز الاستجابة السريعة.

الناتج النهائي هو الختم التشفيري الذي يثبت أمرين معًا: أن الفاتورة صدرت من نظامك صاحب المفتاح الخاص، وأن محتواها لم يتغيّر بعد التوقيع. آلية التوقيع الكاملة بتفاصيلها التقنية ستجدها في المرجع التقني للتوقيع الرقمي، ومقال التوقيع الرقمي في الفاتورة الإلكترونية.

مثال عملي: توليد المفتاح والتوقيع باستخدام OpenSSL

الأمر التالي يولّد مفتاحًا خاصًا على منحنى secp256k1، وهو المنحنى المطلوب في الفوترة الإلكترونية:

openssl ecparam -name secp256k1 -genkey -noout -out ec-private-key.pem

لاستخراج المفتاح العام المقابل من المفتاح الخاص (المفتاح العام فقط هو ما يُرسَل في طلب الشهادة):

openssl ec -in ec-private-key.pem -pubout -out ec-public-key.pem

عند فحص محتوى ملف المفتاح الخاص، ستلاحظ أنه يبدأ بترويسة واضحة تشير إلى نوعه:

-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIIyourPrivateKeyBytesHere...
oAcGBSuBBAAKoUQDQgAE...publicComponent...
-----END EC PRIVATE KEY-----

هذا الملف هو السرّ المطلق. أي شخص يضع يده على هذه الأسطر يستطيع توقيع فواتير باسمك. لاحظ أنه نصّي وقابل للنسخ بسهولة، ولهذا لا يكفي حفظه في ملف عادي على الخادم.

مثال على إنتاج التوقيع برمجيًا

المقطع التالي بلغة JavaScript يوضّح المبدأ: حساب البصمة ثم التوقيع عليها بالمفتاح الخاص. هذا للتوضيح المفاهيمي، والتطبيق الفعلي يلتزم بتفاصيل مواصفة الهيئة.

const crypto = require("crypto");

// 1. بصمة محتوى الفاتورة
const invoiceHash = crypto
  .createHash("sha256")
  .update(invoiceXml)
  .digest();

// 2. التوقيع بالمفتاح الخاص (يبقى داخل النظام)
const signature = crypto.sign(
  "sha256",
  invoiceHash,
  privateKeyPem
);

// 3. التوقيع يُضمَّن في الفاتورة، والمفتاح الخاص لا يغادر
console.log(signature.toString("base64"));

المبدأ الذي يجب أن يترسّخ: المفتاح الخاص يدخل في عملية التوقيع داخل بيئتك فقط. لا يُرسَل عبر الشبكة، ولا يُسجَّل في ملفات السجل (Logs)، ولا يظهر في أي استجابة API.

العشوائية: حجر الأساس في توليد المفتاح

قوّة المفتاح الخاص تبدأ من لحظة توليده. المفتاح الخاص في جوهره عدد عشوائي كبير، وكلما كانت عشوائيته حقيقية، صار تخمينه مستحيلًا عمليًا. هنا يكمن خطر خفيّ كثيرًا ما يغفل عنه المطوّرون: مصدر العشوائية الضعيف ينتج مفاتيح قابلة للتنبؤ.

إذا اعتمد نظامك على مولّد أرقام عشوائية ضعيف، أو على بذرة (Seed) ثابتة أثناء الاختبار ثم نُقلت إلى الإنتاج بالخطأ، فقد تنتج مفتاحين متطابقين على جهازين مختلفين، أو مفتاحًا يستطيع مهاجم تخمين مجاله. القاعدة: استخدم دائمًا مولّد أرقام عشوائية آمن تشفيريًا (CSPRNG) يوفّره نظام التشغيل أو وحدة الأمان المادية.

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

تشريح عملية التوقيع من الداخل

لنفهم لماذا لا يستطيع أحد تزوير التوقيع دون المفتاح الخاص، يفيد أن ننظر إلى ما يجري داخل خوارزمية ECDSA. عند التوقيع، تأخذ الخوارزمية ثلاثة مدخلات: بصمة الفاتورة، والمفتاح الخاص، وقيمة عشوائية مؤقتة تُعرف بالقيمة اللحظية (Nonce). تُنتج هذه المدخلات زوجًا من الأعداد يمثّل التوقيع.

القيمة اللحظية تستحق انتباهًا خاصًا. يجب أن تكون فريدة وعشوائية في كل عملية توقيع. إعادة استخدام القيمة اللحظية نفسها لتوقيع رسالتين مختلفتين بالمفتاح نفسه ثغرة شهيرة تتيح حساب المفتاح الخاص رياضيًا من توقيعين فقط. لهذا تترك توليد القيمة اللحظية للمكتبة التشفيرية الموثوقة، ولا تكتبها بنفسك أبدًا.

هذا يفسّر المبدأ العملي: لا تبنِ التشفير من الصفر. استخدم مكتبات ناضجة مدقَّقة، ودع لها التفاصيل الدقيقة التي يكفي خطأ صغير فيها لإسقاط أمان مفتاحك بالكامل. في نظام إنتاج جادّ، تتولّى المنصة أو وحدة الأمان هذه التفاصيل، فلا تلمس فريق التطوير هذه الحساسيات مباشرة.

لماذا يجب أن يبقى المفتاح الخاص سرًّا مطلقًا

تقوم منظومة الفوترة الإلكترونية بأكملها على افتراض واحد: أن المفتاح الخاص معروف لصاحبه فقط. إذا سقط هذا الافتراض، تنهار الثقة في كل فاتورة وقّعها ذلك المفتاح.

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

هذه خاصية تُسمى عدم الإنكار (Non-repudiation). بما أنك وحدك تملك المفتاح الخاص، لا تستطيع التنصّل من فاتورة وقّعها مفتاحك. هذه الخاصية مفيدة لك ولطرفك المقابل، لكنها تنقلب ضدك تمامًا إذا تسرّب المفتاح: ستُنسب إليك فواتير لم تصدرها أنت.

الفرق بين السرية والعلنية في المنظومة

كيف تحمي المفتاح الخاص: مبادئ راسخة

حماية المفتاح الخاص ليست خطوة واحدة، بل مجموعة مبادئ تُطبَّق في كل مرحلة من دورة حياته. إليك الأسس التي يبني عليها أي نظام فوترة جادّ.

1. لا تخزّن المفتاح كنصّ ظاهر

حفظ المفتاح الخاص في ملف عادي على الخادم أو داخل قاعدة بيانات بصيغة نصّية هو الخطأ الأكثر شيوعًا والأكثر خطورة. أي ثغرة تكشف نظام الملفات تكشف المفتاح. الحدّ الأدنى هو التخزين مشفّرًا، والأفضل هو ألا يلمس المفتاح القرص أصلًا بصيغته الخام.

2. استخدم مخزنًا آمنًا متخصصًا

تُحفظ المفاتيح الخاصة الحساسة في وحدات أمان مادية (Hardware Security Module) أو في خدمات إدارة مفاتيح سحابية مخصصة. هذه الوحدات مصمَّمة بحيث يدخل طلب التوقيع ويخرج التوقيع، دون أن يخرج المفتاح نفسه من الوحدة أبدًا. هذا يحقق المبدأ الأهم: المفتاح لا يغادر حدوده الآمنة.

3. طبّق مبدأ أقل صلاحية

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

4. لا تُسرّب المفتاح في السجلات أو الشيفرة

من أكثر التسريبات إيلامًا أن يُكتب المفتاح في ملف سجلّ تشخيصي، أو يُدرج مباشرة في الشيفرة المصدرية ثم يُرفع إلى مستودع عام. راجع شيفرتك: لا مفتاح خاص في الكود، لا مفتاح في متغيرات بيئة تُطبع في السجلات، لا مفتاح في رسائل الأخطاء.

5. شفّر المفتاح أثناء النقل والتخزين

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

ماذا يحدث إذا تسرّب المفتاح الخاص

تسريب المفتاح الخاص هو السيناريو الأسوأ في منظومة التوقيع. تخيّل أن طرفًا خبيثًا حصل على نسخة من مفتاحك الخاص. ماذا يستطيع أن يفعل؟

• يوقّع فواتير وهمية تبدو صادرة من نظامك بشكل سليم تمامًا.
• ينتحل هويتك أمام الهيئة والمشترين دون أن يكشفه التحقق التشفيري.
• يُنشئ سلسلة فواتير تُنسب إليك، فتتحمّل تبعاتها الضريبية والقانونية.

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

خطوات الاستجابة الفورية عند الاشتباه بالتسريب

إذا اشتبهت في أن مفتاحك الخاص قد تسرّب، تعامل مع الأمر كحادث أمني عاجل:

1. أوقف استخدام المفتاح فورًا في أي عملية توقيع جديدة.
2. راجع إجراءات إلغاء الشهادة وإعادة إصدار CSID مع الهيئة.
3. ولّد زوج مفاتيح جديدًا في بيئتك الآمنة، واطلب شهادة جديدة.
4. دقّق الفواتير الصادرة في الفترة المشبوهة بحثًا عن أي نشاط غير مصرّح به.
5. راجع كيف وصل المهاجم إلى المفتاح، وأغلق الثغرة قبل تركيب المفتاح الجديد.

تدوير المفتاح (Key Rotation) ليس إجراء طوارئ فقط. من الحكمة تدوير المفاتيح دوريًا كجزء من سياسة أمنية وقائية، بحيث تقصُر النافذة الزمنية التي يكون فيها أي مفتاح صالحًا للاستخدام.

لماذا لا يكفي التحقق التشفيري لاكتشاف التزوير

قد يسأل مطوّر: ألا تستطيع الهيئة أن تميّز فاتورة وقّعها مهاجم عن فاتورة وقّعها صاحب المفتاح الأصلي؟ الجواب لا، ما دام المفتاح هو نفسه. التوقيع الرقمي يثبت أن من وقّع يملك المفتاح الخاص، لا أكثر. لا يحمل التوقيع معلومة عن هوية الشخص الجالس خلف الجهاز، بل عن المفتاح المستخدم فقط.

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

الدرس للمطوّر: استثمر جهدك في منع وصول المفتاح إلى أي طرف غير مصرّح له، لأن ما بعد التسريب لا يوجد حلّ تقني يعيد الثقة سوى إلغاء المفتاح وتدويره. لا تعتمد على أن أحدًا في سلسلة التحقق سيلتقط التزوير، فالنظام مصمَّم ليثق بمفتاحك.

مصفوفة المخاطر: من يصل ومتى

كيف يحمي قيود مفتاحك الخاص

عند استخدامك نظام الفوترة الإلكترونية من قيود، تتولّى المنصة إدارة المفتاح الخاص ودورة حياته نيابة عنك، فلا تحتاج إلى بناء طبقة التشفير بنفسك.

إليك ما يقدّمه قيود على هذا الصعيد:

• توليد زوج المفاتيح وإدارة شهادة CSID آليًا عند ربط منشأتك بمنصة فاتورة.
• توقيع كل فاتورة بالختم التشفيري المطلوب في المرحلة الثانية، دون تدخّل يدوي منك.
• التوافق الكامل مع متطلبات هيئة الزكاة والضريبة والجمارك في الإصدار والربط.
• الإصدار الفوري للفواتير الضريبية (B2B) والمبسّطة (B2C) مع رمز الاستجابة السريعة.
• دعم فني متواصل على مدار 24 ساعة طوال أيام الأسبوع لمساعدتك في خطوات الربط.

هذا يعني أنك تركّز على عملك، بينما تتكفّل المنصة بالجانب التشفيري المعقّد الذي تناولناه في هذه المقالة. أنت تصدر الفاتورة، وقيود يتولّى توقيعها وحفظ مفتاحها وربطها بالهيئة.

المفتاح الخاص والمفتاح العام: لكلٍّ دوره

اكتمال الصورة يتطلب فهم الطرف الآخر. المفتاح الخاص يوقّع، والمفتاح العام يتحقّق. هما وجهان لعملية واحدة، لكن أدوارهما لا تتقاطع. المفتاح الخاص ينتج الختم في بيئة سرية، والمفتاح العام يفحص الختم في بيئة علنية.

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

القاعدة التي تختصر كل شيء: عامِل المفتاح العام كأنه معلن للعالم، وعامِل المفتاح الخاص كأنه أثمن سرّ في نظامك. الأول مصمَّم للانتشار، والثاني لا يغادر حدوده الآمنة أبدًا.

الأسئلة الشائعة

ما الفرق بين المفتاح الخاص والمفتاح العام؟

المفتاح الخاص يوقّع الفاتورة وينتج الختم، ويبقى سرًّا عند نظامك. المفتاح العام يتحقق من التوقيع، ويُوزَّع على الجميع داخل شهادة CSID. ما يوقّعه الخاص لا يتحقق منه إلا العام المقابل له.

هل يُرسَل المفتاح الخاص إلى الهيئة؟

لا. عند طلب الشهادة يُرسَل المفتاح العام فقط داخل طلب توقيع الشهادة. المفتاح الخاص لا يغادر نظامك في أي خطوة، وهذا أساس أمان المنظومة.

ماذا يحدث إذا تسرّب المفتاح الخاص؟

يستطيع من يملكه توقيع فواتير باسمك دون أن يكشفه التحقق التشفيري. الإجراء العاجل: إيقاف المفتاح، إلغاء الشهادة، توليد زوج جديد، وطلب شهادة CSID جديدة، مع تدقيق الفواتير الصادرة في الفترة المشبوهة.

ما المنحنى المستخدم لتوليد المفتاح في الفوترة الإلكترونية؟

تعتمد المنظومة منحنى التشفير الإهليلجي secp256k1 بطول 256 بت. يوفّر متانة عالية مع توقيع سريع وحجم صغير يناسب رمز الاستجابة السريعة على الفاتورة.

كيف أحفظ المفتاح الخاص بأمان؟

احفظه في مخزن آمن متخصص أو وحدة أمان مادية، لا في ملف نصّي. طبّق مبدأ أقل صلاحية، امنع تسجيله في السجلات أو إدراجه في الشيفرة، وشفّره أثناء النقل والتخزين.

هل أحتاج إلى إدارة المفتاح الخاص بنفسي مع قيود؟

لا. يتولّى قيود توليد المفاتيح وإدارة شهادة CSID وتوقيع كل فاتورة آليًا. أنت تصدر الفاتورة، والمنصة تتكفّل بالجانب التشفيري والربط مع الهيئة.