21.06.2011 فلاديمير بيزمالي

لقد كتب الكثير عن فوائد التحول إلى Office 2010، ولا أعتقد أن الأمر يستحق تكرار كل الحجج. أود اليوم أن أتحدث عن فوائد هذا الانتقال من وجهة نظر أمان المستندات المشفرة

أولاً، دعونا نتذكر كيف تمت حماية مستندات Microsoft Word في Microsoft Office.

الماضي والحاضر للتشفير في Office

في Office، وحتى الإصدار 6.0، كانت أول خوارزمية تشفير هي XOR البسيطة. وبطبيعة الحال، لم توفر خوارزمية التشفير البسيطة هذه أي حماية، وتم استرداد أي كلمات مرور على الفور تقريبًا. من الطبيعي أن تظهر البرامج المقابلة لاختراق Microsoft Word وMicrosoft Excel على الفور تقريبًا. علاوة على ذلك، كما لاحظ أحد مؤلفي هذه البرامج، فإن الشعور الزائف بالأمان أسوأ بكثير من غيابه. وطلب من Microsoft تحسين الأمان في Office.

وقد تم ذلك في الإصدارات اللاحقة من Microsoft Office 97 و2000. واستخدمت هذه المنتجات خوارزميات تشفير MD5 وRC4 قوية. ومع ذلك، نظرًا للقيود المفروضة على تصدير التشفير القوي التي كانت سارية في الولايات المتحدة في ذلك الوقت، لم تتمكن خوارزميات التشفير المستخدمة خارج الولايات المتحدة من استخدام مفاتيح أطول من 40 رقمًا. أدى ذلك إلى الحد الاصطناعي لمفاتيح RC4 إلى 40 بت، وبالتالي، من أصل 16 بايت المستلمة عند إخراج MD5، تم استبدال 11 بايت ببساطة بـ 0، وتم تشكيل مفتاح RC4 من 5 بايتات مهمة و11 صفرًا. أدى ذلك إلى إمكانية تنظيم هجوم بالقوة الغاشمة. لفك تشفير ملف MS Word/Excel 97/2000، تحتاج إلى فرز 240 مفتاحًا كحد أقصى.

مع الأخذ في الاعتبار ظهور الجداول الرئيسية (جداول قوس قزح)، يمكن تنفيذ الهجوم المطلوب في وقت محدود (من عدة ثوان إلى عدة دقائق). علاوة على ذلك، ظهرت مواقع الإنترنت التي تقدم خدمات مماثلة، على سبيل المثال www.decryptum.com (تكلفة فك تشفير ملف واحد هي 29 دولارًا)؛ البرنامج المضمون لـ Word Decrypter (GuaWord) 1.7، المضمون لـ Excel Decryptor (GuaExcel) 1.7 (المصنع بواسطة PSW-soft)، برنامج Advanced Office Password Breaker (AOPB)، البرنامج المتقدم لاسترداد كلمة المرور للمكتب (AOPR) (المصنع بواسطة Elcomsoft).

في Microsoft Office XP/2003، كانت خوارزمية التشفير الافتراضية هي نفس الخوارزمية بمفتاح 40 بت. ومع ذلك، تم إجراء التغييرات التالية:

• خوارزمية التجزئة SHA1 (بدلاً من MD5)؛
• يمكن أن يصل طول مفتاح RC4 إلى 128 بت؛
• تمت زيادة طول كلمة المرور من 16 إلى 255 حرفًا.

شيء آخر هو أنه على أي حال، فإن نظام التشفير والتحقق من كلمة المرور المستخدم يسمح بسرعة عالية من القوة الغاشمة (تصل إلى 1,000,000 كلمة مرور في الثانية)، كما هو موضح في الشكل 1.

قدم Office 2007 نظام تشفير جديدًا لمكافحة المعدل المرتفع للقوة الغاشمة لكلمة المرور. هناك اختلافات جوهرية فيه عن الإصدار السابق:

• وتم استبدال خوارزمية RC4 بخوارزمية تشفير AES بطول مفتاح يبلغ 128 بت؛
• وبدلاً من التجزئة مرة واحدة، يتم تجزئة كلمة المرور بشكل دوري 50 ألف مرة؛
• من الممكن استخدام خوارزميات تشفير الطرف الثالث.

ونتيجة للتدابير المتخذة، فإن معدل البحث عن كلمة المرور لا يزيد عن 200 كلمة مرور في الثانية، مما يجعل من الممكن تحديد كلمات مرور لا تزيد عن 5-6 أحرف في وقت معقول.

في الوقت نفسه، تجدر الإشارة إلى أنه مع ظهور البرنامج الذي يستخدم موارد بطاقة الفيديو، تزيد سرعة القوة الغاشمة إلى 5 آلاف كلمة مرور في الثانية، والتي من الواضح أنها ليست كافية على أي حال لهجوم كامل القوة الغاشمة ( الشاشة 2).

الشاشة 2. هجوم القوة الغاشمة مع الأخذ بعين الاعتبار موارد بطاقة الفيديو

أما بالنسبة لتنسيق الملفات المحمية، فلا يمكن أن يسمى بسيطة ومفهومة. بعد كل شيء، إذا تم تعيين كلمة مرور لفتح ملف، فإن الملف هو في الواقع حاوية OLE تتكون من معلومات التشفير ودفق مشفر ومعلومات مساعدة. ومع ذلك، على الرغم من أنه، مثل كتلة التشفير في Office XP/2003، فإنه يحتوي على اسم موفر التشفير، وأسماء خوارزميات التجزئة والتشفير، بالإضافة إلى طول المفتاح وبيانات التحقق من كلمة المرور وفك التشفير، في Office 2007 تم تعيين المعلمات التالية بشكل صارم:

• خوارزمية تشفير AES بطول مفتاح 128 بت؛
• خوارزمية التجزئة SHA-1.

في هذه الحالة، يتم توفير التشفير والتجزئة بواسطة Microsoft Enhanced RSA وAES Cryptographic Provider. في الوقت نفسه، يجب أن يؤخذ في الاعتبار أنه عند مهاجمة عمليات البحث المتسلسلة عن كلمات المرور، تنخفض سرعة القوة الغاشمة بشكل كارثي.

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

خيارات أمان المستندات

تتيح لك إعدادات حماية المستندات تغيير كيفية تشفير الملفات والنصوص باستخدام ميزة الحماية بكلمة مرور. هناك نوعان من إعدادات أمان المستندات:

• الإعدادات العامة التي تنطبق على Office Excel 2007 وOffice PowerPoint 2007 وOffice Word 2007. تم توضيح إعدادات أمان المستندات العامة في الجدول 1؛
• الإعدادات الخاصة بالتطبيق والتي تنطبق فقط على Microsoft Office OneNote 2007.

يمكن العثور على هذه الإعدادات إما في صفحة تحرير إعدادات المستخدم في OCT، ضمن نظام Microsoft Office 2007، خيارات الأمان، أو في عقدة تكوين المستخدم/القوالب الإدارية في محرر كائنات نهج المجموعة، ضمن Microsoft System Office 2007/خيارات الأمان. .

إعدادات الخصوصية

تساعد إعدادات الخصوصية على حماية المعلومات الخاصة والسرية. هناك أربع فئات رئيسية لإعدادات الخصوصية التي يمكننا استخدامها في Office 2007. ويمكن تكوين الإعدادات في OCT أو من خلال Group Policy. الفئات الأربع لإعدادات الخصوصية موضحة أدناه.

يظهر خيار Document Inspector في الجدول 2.

يمكن العثور على CLSID لوحدة المفتش في إدخالات التسجيل الموجودة في مفاتيح التسجيل التالية:

HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Excel/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/PowerPoint/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Word/ Document Inspectors

يمكن العثور على خيار Document Inspector في صفحة تحرير خيارات المستخدم في أداة تخصيص Office: 2007 Microsoft Office System (سطح المكتب)/أخرى.

أو يمكنك العثور على هذا الإعداد في محرر كائنات نهج المجموعة: تكوين الكمبيوتر/القوالب الإدارية/Microsoft Office 2007 (الكمبيوتر)/أخرى.

التشفير في اوفيس 2010 تعتمد خوارزميات التشفير المستخدمة في Microsoft Office 2010 على الخوارزميات التي يمكن الوصول إليها من خلال واجهات برمجة التطبيقات في نظام التشغيل Windows. Office 2010، بالإضافة إلى دعم Cryptography API (CryptoAPI)، يدعم أيضًا واجهة CNG (CryptoAPI: Next Generation)، والتي تم توفيرها لأول مرة في Microsoft Office 2007 Service Pack 2 (SP2).

تجدر الإشارة إلى أنه باستخدام CNG، يمكنك تحقيق تشفير أكثر ديناميكية واستخدام وحدات الطرف الثالث. عندما يستخدم Office CryptoAPI، تعتمد خوارزميات التشفير على الخوارزميات المتوفرة في موفر خدمة التشفير (CSP) المضمن في نظام التشغيل Windows.

قائمة موفري خدمة التشفير المثبتين على الكمبيوتر موجودة في مفتاح التسجيل التالي:

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Cryptography/Defaults/Provider

في Office 2010 وOffice 2007 SP2، يمكنك استخدام خوارزميات تشفير CNG التالية وملحقات التشفير CNG الأخرى المثبتة على نظامك: AES، وDES، وDESX، و3DES، و3DES_112، وRC2. خوارزميات التجزئة CNG وغيرها من امتدادات التشفير CNG التي يمكن استخدامها هي: MD2، MD4، MD5، RIPEMD-128، RIPEMD-160، SHA-1، SHA256، SHA384 وSHA512.

عند تشفير المستندات بتنسيق Open XML (DOCX وXSLX وPPTX وما إلى ذلك)، فإن خوارزمية التشفير الافتراضية هي AES (يتم دعم خوارزمية التشفير التي تم اختيارها بواسطة وكالة الأمن القومي (NSA) كمعيار للحكومة الأمريكية في التشغيل أنظمة Windows XP SP2 وWindows Vista وWindows 7 وWindows Server 2003 وWindows Server 2008) بطول مفتاح يبلغ 128 بت، وخوارزمية التجزئة هي SHA1.

خيارات التشفير والتشفير. يسرد الجدول 3 الإعدادات التي تسمح لك بتغيير خوارزميات التشفير عند استخدام إصدارات Microsoft Office التي تستخدم CryptoAPI.

في Office 2010، إذا كنت تريد تغيير إعداد نوع التشفير لملفات Office Open XML المحمية بكلمة مرور، فيجب عليك أولاً تمكين خيار Set Encryption Compatibility وتحديد خيار Use Legacy Format. يتوفر خيار تعيين توافق التشفير في Access 2010 وExcel 2010 وPowerPoint 2010 وWord 2010.

يسرد الجدول 4 الإعدادات التي تتيح لك تغيير خوارزميات التشفير عند استخدام Office 2010. تنطبق هذه الإعدادات على Access 2010 وExcel 2010 وOneNote 2010 وPowerPoint 2010 وProject 2010 وWord 2010.

بالإضافة إلى إعدادات CNG المدرجة في الجدول السابق، بالنسبة لـ Excel 2010 وPowerPoint 2010 وWord 2010، يمكنك تكوين إعداد CNG يسمى "استخدام مفتاح جديد عند تغيير كلمة المرور" والذي يتيح لك تحديد ما إذا كنت تريد استخدام مفتاح تشفير جديد عندما تغيير كلمة المرور. بشكل افتراضي، عند تغيير كلمة المرور الخاصة بك، لا يتم استخدام المفتاح الجديد.

يمكن استخدام خيار تعطيل كلمة مرور واجهة المستخدم لمنع إضافة كلمات المرور إلى المستندات، وبالتالي تعطيل تشفير المستندات. يتحكم هذا الإعداد فيما إذا كان بإمكان مستخدمي Office 2010 إضافة كلمات مرور إلى المستندات. بشكل افتراضي، يمكن للمستخدمين إضافة كلمات المرور.

متوافق مع الإصدارات السابقة من Office. إذا كنت تريد تشفير مستندات Office، فنوصي بحفظها بتنسيق Open XML (DOCX وXLSX وPPTX وما إلى ذلك) بدلاً من تنسيق Office 97-2003 (DOC وXLS وPPT وما إلى ذلك). عند تشفير المستندات الثنائية (DOC، XLS، PPT)، يتم استخدام خوارزمية RC4، وهو أمر غير مستحسن! نظرًا لأن العدد الافتراضي لعمليات إعادة التجزئة هو 100000، فإن معدل القوة الغاشمة لكلمة المرور الافتراضية هو نصف معدل الوصول غير القانوني إلى مستندات Office 2007.

وبالتالي، يمكننا استخلاص نتيجة بسيطة: من وجهة نظر مقاومة هجمات القوة الغاشمة، فإن كلمات مرور المستندات في Microsoft Office 2010 هي الأكثر فعالية على الإطلاق.

فلاديمير بيزمالي ( [البريد الإلكتروني محمي]) - متخصص في الأمان، يحمل الألقاب MVP Consumer Security، وMicrosoft Security Trusted Advisor

مقدمة

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

في ديسمبر 2005، أجرى معهد بونيمون دراسة استقصائية بين مختلف خبراء أمن المعلومات فيما يتعلق بالتشفير وحماية البيانات. ومن بين 6,298 شخصًا شملهم الاستطلاع، استخدم 4% فقط من المشاركين التشفير على مستوى المؤسسة. ومن نفس الاستطلاع، ظهرت ثلاثة أسباب رئيسية للمعارضة المستمرة لقواعد التشفير الرسمية:

• ذكر 69% من المشاركين مشاكل في الأداء؛
• ذكر 44% من المشاركين صعوبات في التنفيذ؛
• تحدث 25% من المشاركين عن التكلفة العالية لتنفيذ خوارزميات التشفير.

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

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

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

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

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

مشاكل تقنية التشفير

وظائف التشفير مطلوبة في جميع أنظمة الكمبيوتر الحديثة متعددة المستخدمين حيث يتم فصل البيانات والعمليات ومعلومات المستخدم بشكل منطقي. لمصادقة مستخدم في مثل هذا النظام، تتم تجزئة تسجيلات الدخول وكلمات المرور ومقارنتها بالتجزئات المتوفرة بالفعل في النظام (أو يتم استخدام التجزئة لفك تشفير مفتاح الجلسة، والذي يتم بعد ذلك التحقق من صحته). لمنع العرض غير المصرح به للمعلومات الشخصية، قد يتم تخزين ملفات فردية أو أقسام بأكملها داخل حاويات مشفرة. وتسمح بروتوكولات الشبكة، على سبيل المثال، SSL\TLS وIPSec، إذا لزم الأمر، بتعزيز حماية التشفير للأجهزة المختلفة (/dev/random، /dev/urandom، وما إلى ذلك) باستخدام خوارزميات معيارية تعمل مع نواة نظام التشغيل .

الهدف من أي تقنية لتشفير القرص هو الحماية من الوصول غير المرغوب فيه إلى المعلومات الشخصية وتقليل الضرر الناتج عن فقدان الملكية الفكرية بسبب الوصول غير القانوني إلى الجهاز الفعلي أو سرقته. قدم نظام التشغيل Linux المزود بإصدار kernel 2.6.4 بنية أساسية متقدمة للتشفير تعمل على حماية البيانات الشخصية ببساطة وبشكل موثوق في العديد من طبقات البرامج. توجد معايير كاملة لتخزين البيانات المشفرة على مستوى منخفض، مثل Linux Unified Key Setup (LUKS)، وعمليات التنفيذ على مستوى المستخدم، على سبيل المثال، أنظمة الملفات EncFS وCryptoFS، والتي تعتمد بدورها على Fast Userspace نظام الملفات (FUSE) لنظام التشغيل Linux. وبطبيعة الحال، فإن أي نظام تشفير يكون مقاومًا للقرصنة مثل كلمات المرور ومفاتيح الوصول الخاصة به. هناك ثلاثة مستويات رئيسية يتم فيها استخدام تقنيات التشفير:

• مستوى نظام الملفات والملفات (تشفير ملف تلو الآخر، حاوية الملف)؛
• مستوى كتلة منخفض (حاوية مع نظام الملفات)؛
• مستوى الأجهزة (أجهزة التشفير المتخصصة).

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

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

بعض تقنيات التشفير مجانية ومضمنة في العديد من التوزيعات. بالمناسبة، تم تجهيز أحدث إصدارات Windows بنظام ملفات خاص يدعم نظام الملفات المشفرة (EFS). يدعم Fedora عددًا من خيارات التشفير، بما في ذلك LUKS (يمكنك تمكين دعم LUKS على نظام التشغيل Windows إذا كنت تستخدم أنظمة الملفات FAT أو FAT32 وتطبيق FreeOTFE). ويتوفر FUSE وEncFS في حزم الإضافات. يمكن أيضًا تثبيت CryptoFS عن طريق التنزيل من الموقع الرسمي. .

تتكون البنية التحتية لـ FUSE من وحدة kernel قابلة للتحميل ومكتبة مساحة مستخدم تعمل كأساس لكل من نظامي ملفات CryptoFS ونظام الملفات المشفر (EncFS). من خلال هيكله، لا يؤثر FUSE على الكود المصدري لـ kernel وفي نفس الوقت يوفر مرونة عالية لتنفيذ العديد من الإضافات المثيرة للاهتمام، على سبيل المثال، نظام ملفات Secure Shell (SSHFS).

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

يعد نظام الملفات EncFS أيضًا أحد تطبيقات مساحة المستخدم استنادًا إلى مكتبة FUSE، التي توفر الحماية ضد سرقة المعلومات وتعمل على مبدأ تشفير ملف تلو الآخر. لقد ورث هيكله من الإصدارات السابقة، ولكن مع تحسينات في الشكل والوظيفة. يمكن توسيع نظام الملفات EncFS ديناميكيًا لتلبية متطلبات المستخدم المتزايدة. يمكن تشفير الملفات وفقًا لمعلمات مختلفة (على سبيل المثال، عندما يتغير المحتوى، حسب السمات، وما إلى ذلك). بشكل أساسي، يمكن أن يكون التخزين الأساسي لـ EncFS أي شيء بدءًا من صورة ISO إلى قسم الشبكة أو حتى نظام الملفات الموزع.

يعمل كلا نظامي الملفات على أساس شامل ويمكن استخدامه فوق أنظمة الملفات الأخرى والتجريدات المنطقية، مثل نظام الملفات المسجل أو الموسع، والذي يمكن توزيعه عبر وسائط مادية متعددة عبر مدير قسم منطقي (LVM) ). يوضح الرسم التوضيحي التالي بشكل تخطيطي كيفية عمل نظام الملفات هذا: في هذا الرسم التخطيطي، تمت تسمية الدليل المرئي باسم /mount (طبقة بيانات النص العادي لـ EncFS).

تراكب مساحة المستخدم يُظهر التفاعل بين FUSE وEncFS.

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

يعمل LUKS دون معرفة دقيقة بتنسيق نظام الملفات.

تم تصميم LUKS وفقًا لإعداد المفتاح الموثوق رقم 1 (TKS1) وهو متوافق مع Windows باستخدام أي تنسيق نظام ملفات شائع (FAT/FAT32). النظام مناسب تمامًا لمستخدمي الأجهزة المحمولة، ويدعم إصدار وإلغاء مفتاح Gnu Privacy Guard (GPG)، وهو مجاني تمامًا. LUKS قادر على القيام بما هو أكثر بكثير من أي تطبيق آخر تم وصفه في هذه المقالة. علاوة على ذلك، يدعم LUKS عددًا كبيرًا من الحلول لإنشاء وإدارة أجهزة LUKS المشفرة.

يقبل نظام الملفات CryptoFS كلمة المرور فقط، بينما تعمل الوسائط المشفرة باستخدام LUKS مع أي مفاتيح PGP (خصوصية جيدة جدًا) مع أي عدد من كلمات المرور. يستخدم EncFS أيضًا كلمة مرور لحماية الملفات، ولكنه يفتح المفتاح المخزن في الدليل الجذر المقابل.

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

تكوين الاختبار

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

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

تثبيت

تتوفر LUKS وFUSE وEncFS في توزيعة Fedora، لذا لا يلزم بذل أي جهد إضافي. ولكن يجب تنزيل CryptoFS بشكل منفصل.

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

عملية تثبيت CryptoFS بسيطة.

يتكون الإعداد من تحديد مسارات أدلة البداية والنهاية (للبيانات المشفرة وغير المشفرة). يمكنك بعد ذلك تشغيل أمر cryptofs كما هو موضح في الشكل التالي.

إعداد CryptoFS.

يمكنك بعد ذلك تشغيل أمر التحميل، وبعد ذلك يمكنك رؤية القسم المثبت.

تأكد أولاً من تحميل وحدة FUSE kernel (modprobe fuse). يعمل EncFS على تبسيط عملية إنشاء حاوية مشفرة، كما هو موضح في الرسم التوضيحي التالي.

إذا تخطيت عملية تثبيت المفتاح (التي تخص كل موقف)، فيمكن تكوين LUKS بسهولة كما هو موضح أدناه.

الاختبارات وتحليل الأداء

تعتبر اختلافات الأداء بين التثبيت الأصلي والتثبيت في بيئة LUKS المشفرة بسيطة إلى حد ما. خاصة بالنظر إلى الاختلاف الملحوظ بين حلول مساحة المستخدمين. لتقييم أداء أنظمة الملفات المشفرة واحدًا تلو الآخر، استخدمنا Iozone. بالنسبة للاختبارات، يتم استخدام سجلات يتراوح حجمها من 4 كيلو بايت إلى 16 ميجا بايت، ويتراوح حجم الملف من 64 كيلو بايت إلى 512 ميجا بايت، ويتم الإشارة إلى النتيجة بالكيلوبايت/ثانية.

خاتمة

على الأقل عند استخدام LUKS، لا داعي للقلق بشأن الأداء. على الرغم من أن بعض فقدان الأداء يحدث بالطبع بسبب تشفير البيانات "الشفاف". نظام LUKS سهل وبسيط التثبيت، ويمكن استخدامه على كل من Linux وWindows.

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

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

رأي المحرر

CryptoFS وEncFS هما تطبيقات مساحة المستخدم. وكما أوضحنا سابقًا، فهي بسيطة في التصميم والتنفيذ، ولكنها تأتي على حساب الأداء والقدرات. وهذا واضح بشكل خاص عند مقارنته بـ LUKS. فهو ليس أسرع بشكل ملحوظ فحسب، بل إنه يدعم أيضًا مفتاح PGP واحدًا أو أكثر ويمكن استخدامه عبر القسم بأكمله.

تعد حاويات مساحة المستخدم مهمة في المقام الأول للمستخدمين الذين يرغبون في حماية المعلومات الشخصية في بيئة متعددة المستخدمين. ومن يحتاج إلى حماية بياناته حتى لا يتمكن المسؤول من الوصول إلى موارد الأجهزة أو البرامج. بالإضافة إلى فوائد الأداء والدعم عبر الأنظمة الأساسية، يتكامل LUKS بشكل جيد مع أنظمة إدارة المفاتيح GNOME وPGP. كما أن سهولة الاستخدام اليومي لأقسام LUKS المشفرة أمر مثير للإعجاب بكل بساطة. بالمناسبة، يدعم EncFS وحدة المصادقة القابلة للتوصيل (PAM) ضمن Linux في البيئات المناسبة.

في نهاية نوفمبر 2006، أصدرت Microsoft الإصدار النهائي من مجموعة تطبيقات Microsoft Office 2007. ستقدم هذه المقالة تحليلاً للتغييرات الرئيسية المتعلقة بحماية المستندات والبيانات الشخصية للمستخدم.

تنسيق الملف الجديد

يمكن ملاحظة تغيير التنسيق على الفور؛ على سبيل المثال، تحتوي ملفات Word 2007 الآن على ملحق *.docx بدلاً من الامتداد *.doc المعتاد. في الإصدارات السابقة من Office، كانت معظم الملفات عبارة عن حاويات OLE، والتي تتكون بدورها من عدة تدفقات من البيانات الثنائية. تم توثيق التنسيقات الثنائية Word وExcel وإتاحتها لمشتركي MSDN في أواخر التسعينيات. ومع ذلك، مع إصدار Office 2000، أغلقت Microsoft هذه التنسيقات، وحتى Office 2003 لم تكن متاحة حتى لشركائها. هذا جعل من المستحيل كتابة التطبيقات الخاصة بك التي تعمل مع مستندات Office.

ومع ذلك، مع إصدار Office 2007، تغير الوضع بشكل جذري. تنسيق ملف Office Open XML الجديد مفتوح وموثق بالكامل. تتوفر الوثائق المتعلقة بالتنسيق ويمكن لأي شخص تنزيلها من موقع Microsoft على الويب. اتبعت Microsoft هنا مسار مشروع OpenOffice المعروف، والذي يكون تنسيق ملفه مفتوحًا أيضًا ويستخدم XML لتخزين البيانات. نظرًا لأن تنسيق XML، على عكس التنسيق الثنائي، يحتوي على الكثير من المعلومات الزائدة عن الحاجة، فإن جميع ملفات XML يتم تجميعها باستخدام طريقة الانكماش الخاصة بأرشيف ZIP.

على سبيل المثال، هذا ما يبدو عليه ملف document.xml، وهو "نص" مستند Word:

org/markup-compatibility/2006" xmlns:o="urn:

المخططات-مايكروسوفت-com:office:office” xmlns:r=

"http://schemas.openxmlformats.org/officeDocument/

2006/العلاقات”xmlns:m=”http://schemas.

openxmlformats.org/officeDocument/2006/math"

xmlns:v=”urn:schemas-microsoft-com:vml” xmlns:wp=

"http://schemas.openxmlformats.org/drawingml/2006/

رسم معالجة النصوص” xmlns:w10=”urn:schemas-

Microsoft-com:office:word” xmlns:w=”http://

schemas.openxmlformats.org/wordprocessingml/2006/

الرئيسي” xmlns:wne=”http://schemas.microsoft.com/

مكتب/وورد/2006/ووردمل">

w:rsidRDefault=”00FC4BE5”>

اختبار ملف الوورد...

w:rsidSect=”00021ED4”>

w:left=”1701” w:header=”708” w:footer=”708”

w:مزراب=”0” />

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

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

حماية ملفات Office 2007: Word وExcel وPowerPoint

على الرغم من أن تنسيق ملفات Office العادية بسيط جدًا ومفهوم، إلا أنه لا يمكن تسمية تنسيق الملفات المحمية بهذا الشكل. إذا تم تعيين كلمة مرور لفتح الملف، فإن الملف عبارة عن حاوية OLE تتكون من معلومات التشفير ودفق مشفر ومعلومات مساعدة. كتلة معلومات التشفير هي نفسها تمامًا الموجودة في Office XP/2003. يحتوي على اسم موفر التشفير وخوارزميات التجزئة والتشفير، بالإضافة إلى طول المفتاح وبيانات التحقق من كلمة المرور وفك تشفير المستند. ومع ذلك، إذا كان من الممكن في الإصدارات السابقة من Office تغيير موفر التشفير وطول المفتاح، فسيتم تعيين المعلمات التالية بشكل صارم في Office 2007: خوارزمية تشفير AES بطول مفتاح يبلغ 128 بت وتجزئة SHA-1. يتم توفير التشفير والتجزئة بواسطة موفر التشفير Microsoft Enhanced RSA وAES.

ومع ذلك، بالمقارنة مع Office 2003، فقد تغيرت خوارزمية تحويل كلمة المرور إلى مفتاح. في السابق، كانت كلمة المرور تُجزأ ببساطة مع مجموعة عشوائية من البايتات الفريدة لكل مستند (ملح). تطلبت هذه العملية تحويلين فقط من نوع SHA-1 وكانت سريعة جدًا. الآن، لتحويل كلمة المرور إلى مفتاح، تحتاج إلى إجراء 50 ألف تحويل SHA-1 بالتتابع. عند فتح مستند، يكون هذا غير محسوس - تكتمل العملية في جزء من الثانية. ومع ذلك، عندما نبدأ في تجربة كلمات المرور بشكل تسلسلي، تنخفض سرعة البحث بشكل كارثي. وفقا للتقديرات الأولية، لا يمكن أن يكون أكثر من 500 كلمة مرور في الثانية، حتى على معالجات Intel Core 2 Duo الحديثة. لذلك، إذا كنت تستخدم قوة الحوسبة لجهاز كمبيوتر واحد فقط، فمن الممكن بالفعل العثور على كلمة مرور يصل طولها إلى 4-5 أحرف.

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

مثال لتخزين معلومات حول كلمة مرور للقراءة فقط في Word 2007:

w:cryptAlgorithmClass=”hash” w:cryptAlgorithmType=

”typeAny” w:cryptAlgorithmSid=”4” w:cryptSpinCount=

”50000" w:hash=”L419ICUXKWKS4zJGA1QoY80b6ds=” w:salt=

”gmd47MvIcN4OwJ5dPxZL6Q==” />

نرى هنا أنه يتم استخدام نفس التكرارات البالغ عددها 50 ألفًا لتجزئة SHA-1، لذلك لم يعد من المستحيل العثور على كلمة المرور هذه على الفور. ومع ذلك، فإن انفتاح التنسيق يبسط المهمة إلى حد كبير إذا كنت بحاجة إلى تغيير كلمة المرور هذه أو إزالتها. يمكننا إما إعادة حساب تجزئة كلمة المرور الجديدة أو إزالة هذه العلامة من ملف XML تمامًا. يتم تخزين كلمات المرور لحماية المستندات، بالإضافة إلى مصنفات وأوراق Excel بنفس الطريقة.

تطبيقات مايكروسوفت أوفيس الأخرى

لقد تغير نظام الأمان في Microsoft Access بشكل ملحوظ. إذا كانت كلمة المرور لفتح ملف مخزنة مسبقًا في الرأس بنص واضح تقريبًا، فإن Access 2007 يستخدم تشفير الملفات، ويتم تنفيذه وفقًا لنفس المبدأ كما هو الحال في Word/Excel. الآن لا يمكن استرداد كلمة المرور هذه على الفور، وسيستغرق استعادتها بالقوة الغاشمة المباشرة وقتًا طويلاً. يقوم Access 2007 بإزالة الأمان على مستوى المستخدم ومجموعة المستخدمين.

لم تخضع حماية ملفات Microsoft Outlook PST لأية تغييرات. كما كان من قبل، يتم تخزين فقط تجزئة 32 بت (CRC-32) من كلمة المرور في الملف، والتي يمكن عكسها بسهولة.

استراتيجيات حماية واستعادة كلمات مرور Office 2007

بادئ ذي بدء، أود أن أشير إلى أنه بشكل عام، تم تعزيز حماية مستندات Office في الإصدار الجديد من الحزمة بشكل كبير. لقد استغرق الأمر من Microsoft 10 سنوات فقط (منذ إصدار Office 97) لتطوير حماية جيدة. كلمة المرور المستخدمة لفتح ملف قوية جدًا، وقد تستغرق تجربتها وقتًا طويلاً جدًا. لكن هذا لا يلغي الحاجة إلى اختيار كلمات مرور قوية للمستندات. ولسوء الحظ، فإن العامل البشري كان دائما وسيظل أضعف نقطة في أي دفاع. وحتى الحماية القوية لـ Office 2007 لن تساعد إذا اختار المستخدم كلمة المرور John أو love أو sex - فسيتم استعادتها على الفور باستخدام القاموس.

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

تنطبق الحماية القوية فقط على كلمات المرور لفتح المستندات. لا يزال يتم العثور على جميع كلمات المرور الأخرى على الفور أو يمكن تغييرها أو حذفها.

CryptoUtility - مكون يسمح لك بتطبيق تشفير قوي في تطبيقاتك

• 12/05/2008
• زمن القراءة: 19 دقيقة

في هذه المقالة

• مايكل ستيوارت
• جاي سوير

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

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

في هذه المقالة، سنلقي نظرة على بعض التحديات التي تواجه تطوير مكونات تشفير قوية تستخدمها التطبيقات. ستكون هذه المكونات مفيدة في حالات مثل تلك الموضحة أعلاه. بالإضافة إلى ذلك، عند إنشاء برنامج CryptoUtility، تابعنا بعض الأهداف الأخرى. أولاً، أردنا توفير أعلى مستوى من الأمان المنطقي لتطبيقات الويب من جانب الخادم. ثانيًا، يجب أن يكون التثبيت بسيطًا نسبيًا من وجهة نظر المسؤول وأن يمكن نشر البرنامج على خوادم متعددة دون الحاجة إلى المرور عبر 10 صفحات من تعليمات التثبيت. ثالثًا، يجب دعم التشفير القابل للعكس (والذي سننظر إليه لاحقًا) ويجب أن تكون المفاتيح آمنة وغير معرضة للخطر عند تخزينها. بالطبع، نظرًا لأن هذا تطبيق خادم، فيجب أن يكون قابلاً للتطوير بشكل كبير وقادرًا على التشغيل لعدة أشهر دون إشراف المسؤول أو الحاجة إلى إعادة التشغيل. وأخيرًا، أردنا أن يكون المكون متاحًا لكل من تطبيقات COM القديمة (مثل ASP الكلاسيكي) وتطبيقات .NET (مثل خدمات الويب وتطبيقات الويب التي تعمل في ASP.NET).

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

وسوف نستكشف التهديدات باستخدام نموذجي STRIDE وDREAD اللذين وصفهما مايكل هوارد في كتابه "كتابة الكود الآمن"، الإصدار الثاني (Microsoft Press، 2003). STRIDE هو نموذج لتقسيم التهديدات إلى فئات. يرمز هذا الاختصار إلى الانتحال والتلاعب والكشف عن المعلومات ورفض الخدمة ورفع الامتيازات. DREAD - نموذج لحساب المخاطر الإجمالية المرتبطة بالتهديد؛ هذا اختصار لـ احتمالية الضرر، وقابلية التكرار (احتمال تكرار الهجوم)، وقابلية الاستغلال (مدى سهولة تنفيذ هجوم)، والمستخدمين المتأثرين (المستخدمين المتأثرين)، وقابلية الاكتشاف (مدى سهولة اكتشاف الثغرة الأمنية). . تقع نمذجة التهديدات وتحليلها خارج نطاق هذه المقالة، لكننا سنستخدم مصطلحات نماذج STRIDE وDREAD عند مناقشة إجراءات أمان النظام.

بنية CryptoUtility

القرارات المعمارية لها تأثير على أي تطبيق. أولاً، كان علينا أن نقرر كيفية تنفيذ CryptoUtility: كمكتبة الارتباط الحيوي (DLL) قيد المعالجة، أو كخدمة Windows، أو كمكون مخدوم يعمل في خدمات المؤسسة. قد يؤدي تطوير أحد المكونات كمكتبة الارتباط الحيوي (DLL) قيد التشغيل إلى تقديم العديد من المشكلات الأمنية الخطيرة. أولاً، سيتم تشغيل CryptoUtility ضمن حساب ASP.NET. على الرغم من أننا لم نقرر بعد استراتيجية إدارة المفاتيح (سنفعل ذلك لاحقًا)، إلا أننا بالتأكيد لا نريد أن يتمكن حساب ASP.NET من الوصول إلى المفتاح. ومن ثم سيكون هناك احتمال أن يستغل المهاجم هذه الثغرة الأمنية ويحصل على معلومات حساسة من خلال موقع الويب. إن فرص حدوث ذلك ضئيلة، لكن البيانات التي نحميها تجعل احتمال الاختراق التدميري مرتفعًا للغاية. يمكن أن يؤثر هذا النوع من التطفل على جميع المستخدمين، لذلك نحاول عدم استخدام هذا الأسلوب أبدًا.

يمكننا استخدام نموذج Code Access Security (CAS) مع الاتصال عن بعد، ولكن نظرًا لنقص الدعم لعملاء COM، فإن هذا ليس الخيار الأفضل. ومع ذلك، سننظر في CAS بشكل أكبر في هذه المقالة.

يوفر المكون المخدوم في Enterprise Services نفس المزايا التي توفرها خدمة Windows. مثل هذا المكون يعمل تحت هويته الخاصة بهوياته الخاصة. بالإضافة إلى ذلك، تعتمد تقنية Enterprise Services على تقنية COM+ Component Services، مما يوفر لعملاء COM تحكمًا قويًا في الوصول وسهولة الوصول. لذلك، قررنا أن نجعل CryptoUtility مكونًا صالحًا للخدمة.

حلول التشفير

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

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

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

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

كيف تعمل الخوارزميات المتماثلة

الخوارزميات المتماثلة من النوع المذكور في المقالة هي عبارة عن شفرات كتلة. يقومون بتقسيم النص العادي إلى كتل ذات حجم ثابت (في حالة خوارزمية Rijndael، 16 أو 24 أو 32 بايت) وتنفيذ عمليات التقليب والاستبدال لكل كتلة في الحلقة. في .NET Framework، يمكنك الاختيار من بين العديد من الخوارزميات المتماثلة: DES (معيار تشفير البيانات)، والذي كان في السابق معيارًا فيدراليًا، أو 3DES (Triple-DES)، أو RC2، أو Rijndael. لقد فقدت DES قوتها عندما أصبحت الأجهزة أكثر قوة: نظرًا لأنها تستخدم مفتاح 56 بت فقط، فهي عرضة لهجمات القوة الغاشمة. لا تزال خوارزمية Triple-DES آمنة نسبيًا وربما تكون مناسبة تمامًا للتشفير لأنها مدعومة على نطاق واسع في معظم الأنظمة الأساسية.

لقد اخترنا خوارزمية Rijndael لـ CryptoUtility لأنها يمكن أن تستخدم مفاتيح 256 بت، وهو أكبر حجم من أي خوارزمية مدمجة في .NET. بالإضافة إلى ذلك، أصبح Rijndael هو معيار التشفير المتقدم الجديد الذي تبنته الحكومة الفيدرالية في عام 2001 كبديل لـ DES. جاء ذلك بعد مراجعة مطولة وشاملة للعديد من الخوارزميات في مسابقة برعاية NIST.

معلمات الخوارزميات المتماثلة

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

وضع التشفير (الوضع) في حالة خوارزمية Rijndael، يكون إما CBC (Cipher Block Chaining) أو ECB (كتاب الرموز الإلكترونية):

• يعد CBC، الوضع الافتراضي في .NET، هو وضع التشفير الأكثر أمانًا. في وضع CBC، تقوم الخوارزمية بإرجاع كل كتلة نص عادي إلى الكتلة المشفرة السابقة قبل تشفير النص. يتطلب هذا الوضع أيضًا متجه تهيئة (IV) - كتلة عشوائية بنفس حجم كتلة الخوارزمية. يتم استخدام IV بدلاً من الكتلة بحيث يمكن تنفيذ عملية Cipher Block Chaining على أول كتلة نص عادي، نظرًا لأن هذه الكتلة ليس لها كتلة سابقة. IV يضمن أن وجود التكرارات في كتلة النص العادي الأولى عند استخدام نفس المفتاح لن يؤدي إلى نفس التكرار في كتلة النص المشفر الأولى؛
• يعد البنك المركزي الأوروبي (ECB) وضعًا أقل أمانًا حيث يتم تشفير كل كتلة بشكل مستقل عن الكتل الأخرى. يمكن أن يؤدي التكرار في النص العادي إلى ظهور أنماط في النص المشفر، مما يؤدي إلى إضعاف الأمان.

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

• PKCS7 - الكتلة الأخيرة مليئة بقيم عددية، يمثل كل منها عدد البايتات المضافة إلى الرسالة. على سبيل المثال، إذا كانت هناك حاجة إلى إضافة 2 بايت إلى الرسالة، فستتم إضافة "0x02، 0x02""؛
• لا شيء - لا تتم إضافة أي شيء. يجب أن يكون طول الرسالة مضاعفًا لطول كتلة الخوارزمية؛
• الأصفار - الكتلة الأخيرة مبطنة بالأصفار.

حجم المفتاح - طول المفتاح المستخدم للتشفير وفك التشفير.توفر المفاتيح الأطول عمومًا أمانًا أفضل لأن هجمات القوة الغاشمة أقل احتمالية للنجاح. يستخدم Rijndael أحجام مفاتيح تبلغ 128 أو 192 أو 256 بت. لا يعتمد حجم المفتاح على حجم الكتلة.

حجم الكتلة - طول كل كتلة.في Rijndael، يمكن أن يكون حجم الكتلة 128 و192 و256 بت.

لاحظ أن جميع المجموعات التسعة من أحجام الكتل والمفاتيح ممكنة في Rijndael؛ ومع ذلك، يجب أن يتطابق حجم IV مع حجم الكتلة. من الأفضل استخدام كتل أكبر، نظرًا لأن Rijndael يمكنه إجراء 10 إلى 14 تكرارًا داخليًا عند التشفير، وكلما زاد حجم الكتلة والمفاتيح، زاد عدد التكرارات. وكلما زاد عدد التكرارات التي تقوم بها خوارزمية Rijndael، زادت مقاومة التشفير لتحليل التشفير. لمزيد من المعلومات حول Rijndael، راجع مقالة جيمس ماكافري حول الخوارزمية في مجلة MSDN، نوفمبر 2003.

قررنا استخدام وضع Cipher Block Chaining وأحجام الكتل والمفاتيح التي تبلغ 256 بت لتوفير أقصى مستوى من أمان النص المشفر. يعد ناقل CBC ومتجه التهيئة أمرًا بالغ الأهمية: تبدأ العديد من أرقام بطاقات الائتمان بنفس الأرقام. إذا كان النص المشفر لهذه البطاقات يبدأ أيضًا بنفس البيانات، فسيكون من الأسهل على المهاجمين الوصول إلى أرقام بطاقات الائتمان المشفرة وسرقة البيانات!

إنشاء مفاتيح قوية

مثل كلمات المرور التي يمكن التنبؤ بها، تشكل مفاتيح التشفير التي يمكن التنبؤ بها خطرًا كبيرًا على أمان التطبيق الخاص بك. لا تقم بإنشاء هذه المفاتيح يدويًا: فالبشر هم مولدات أرقام عشوائية سيئة. مولد الأرقام العشوائية الزائفة System.Random غير مناسب أيضًا، نظرًا لأن تسلسلاته العشوائية حتمية ومتكررة (ومن هنا جاء اسم "العشوائية الزائفة"). لإنشاء مفاتيح قوية، يمكنك استخدام RNGCryptoServiceProvider. فهو يولد أرقامًا عشوائية قوية من الناحية التشفيرية ومناسبًا لإنشاء المفاتيح والامتدادات/الرموز IV. على الرغم من كونه منشئ أرقام عشوائية زائفة من الناحية الفنية، إلا أن RNGCryptoServiceProvider معتمد من قبل NIST باعتباره قويًا من حيث التشفير. يستخدم مثال التعليمات البرمجية لـ Visual Basic .NET التالي RNGCryptoServiceProvider للحصول على 32 بايت عشوائي من البيانات:

الإنتروبيا الخافتة كـ Byte() = ... Dim pwd كـ PasswordDeriveBytes = _ New PasswordDeriveBytes(txtKey.Text, entropy) المفتاح الخافت كـ Byte() = pwd.GetBytes(32)

إنشاء ملحقات مستمرة

تقدم الامتدادات إنتروبيا إضافية (درجة معينة من الاضطراب) إلى خوارزميات التشفير. عند إنشاء IV، سنستخدم نفس الطريقة المستخدمة في المفتاح - استخدم منشئ الأرقام العشوائية RNGCryptoServiceProvider:

Dim rng As RNGCryptoServiceProvider = _ New RNGCryptoServiceProvider() Dim entropy As Byte() = New Byte(15) rng.GetBytes(entropy)

عند خلط الكتل، تستخدم خوارزمية التشفير IV ككتلة أولية لإخفاء جميع الأنماط في الكتلة الأولى. في وضع CBC، يتم استخدام كل كتلة لتشفير الكتلة التالية، ويتم استخدام IV لتشفير الكتلة الأولى.

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

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

"ضع IV في بداية النص المشفر الناتج = New Byte(IV_SIZE + data.Length - 1) Buffer.BlockCopy(newIV, 0,output, 0, newIV.Length) Buffer.BlockCopy(data, 0,output,IV_SIZE, data. length) " خذ الامتداد (IV) من أول 16 بايت من الإدخال Buffer.BlockCopy(cipherBlob, 0, iv, 0, IV_SIZE) " ضع النص المشفر في مصفوفة النص المشفر Buffer.BlockCopy(cipherBlob, IV_SIZE, cipherText. , 0, _ (cipherBlob.Length - IV_SIZE))

التشفير الصحي

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

إذا تم وضع نص عادي في كائن System.String، فسيظل بدون تغيير في الذاكرة حتى تتم الكتابة فوقه بواسطة مجموعة البيانات المهملة. تحتوي TextBox وLabel والعديد من عناصر التحكم الأخرى على خاصية نص من النوع System.String. يتغير هذا إلى حد ما في .NET Framework 2.0، الذي يقدم فئة SecureString، المصممة خصيصًا لتخزين السلاسل بشكل آمن (للحصول على معلومات حول SecureString، راجع وثائق Visual Studio 2005 Beta 1.) ولكن هذا لا يحل المشكلة، نظرًا لأن يتم تخزين النص العادي في الذاكرة من العديد من المصادر الأخرى مثل TextBox وما شابه. إذا تمت كتابة نص عادي بأي شكل من الأشكال (مصفوفة بايت، سلسلة، مصفوفة أحرف، وما إلى ذلك) إلى ملف الصفحة بواسطة نظام التشغيل، فسينتهي الأمر على القرص الصلب. إذا تعطل النظام وقام بإنشاء ملف تفريغ للذاكرة أثناء وجود نص عادي في الذاكرة، فسيتم كتابة هذا النص أيضًا على القرص.

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

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

ومع ذلك، يجب اتباع قواعد "النظافة" معينة عند كتابة التعليمات البرمجية لتقليل مخاطر مثل هذه الهجمات. أولاً، قم بتقليل وقت تخزين المفتاح في الذاكرة غير مشفر: قم بتشفير المفتاح عبر DPAPI (واجهة برمجة تطبيقات حماية البيانات) وقم بتخزينه في مفتاح تسجيل محمي بقائمة التحكم بالوصول (ACL). قم بفك تشفير المفتاح مباشرة قبل الاستخدام، ثم قم بمسح مصفوفة البايت باستخدام طريقة Array.Clear، التي تقوم بمسح البايتات. لا تقم مطلقًا بتخزين مفتاح في كائنات السلسلة، حتى تلك التي تم تشفيرها باستخدام Base64؛ تذكر أن Base64 لا يمكن اعتباره تشفيرًا. لاحظ أن مسح مصفوفة البايت بهذه الطريقة لا يحل المشكلة تمامًا، حيث قد يقوم جامع البيانات المهملة بتحريك مصفوفة البايت في الذاكرة قبل مسحها. لتجنب ذلك، قم بتعيين عنوان محدد لمصفوفة البايت في الذاكرة - وهذا سيمنع أداة تجميع البيانات المهملة من نقلها. للحصول على معلومات حول قوائم ACL، راجع مقالة Mark Pustilnik، "الأمان في Windows. التحكم في الوصول إلى كائنات Windows استنادًا إلى قوائم ACL و.NET Framework" في هذه المشكلة.

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

تخزين المفاتيح

في التطبيقات العملية، الجزء الأكثر أهمية في التشفير هو تخزين المفاتيح. بروس شناير، خبير أمن الكمبيوتر ومؤلف كتاب التشفير التطبيقي (جون وايلي وأولاده، 1996)، وصف ببراعة نقاط الضعف في الأمن الذي يعتمد فقط على التشفير القوي. وشبه هذه الحماية بسياج يتكون من لوح واحد فقط، ولكن ارتفاعه ميل واحد. وبما أن المفتاح في التشفير المتماثل سري، فإن السؤال الذي يطرح نفسه: كيف نحميه؟ من وجهة نظر المهاجم، يعد الكشف عن المفتاح خيارًا أفضل بكثير من تطبيق أساليب القوة الغاشمة على النص المشفر. لماذا تتسلق سياجًا يبلغ ارتفاعه ميلًا بينما يمكنك التجول حوله؟

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

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

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

حماية المفاتيح المستندة إلى ACL

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

من خلال كتابة التعليمات البرمجية التي تحدد قوائم ACL لمفاتيح التسجيل، يمكننا تغليف تكوين المفتاح مباشرة في برنامج التثبيت أو في أداة مساعدة بسيطة لسطر الأوامر تعمل على تشغيل التثبيت وتكوين الأمان تلقائيًا. لسوء الحظ، لا يحتوي .NET Framework 1.x على وسيلة مضمنة لإعداد قوائم ACL لمفاتيح التسجيل. ولكن بفضل جهود Renaud Paquet، ظهرت مكتبة مُدارة مفيدة للغاية تسمح لك بتعيين قوائم ACL لكل شيء تقريبًا. مكتبة إدارة Reno.NET ACL.

باستخدام مكتبة Win32 Security، قمنا بتقييد الوصول إلى مفتاح التسجيل (الشكل 1). الآن، لقراءة القسم، يجب على المهاجم إما أن يتخذ الهوية المحددة في قائمة التحكم بالوصول (ACL) أو أن يصبح مسؤول الكمبيوتر.

القائمة 1. حماية مفتاح التسجيل

" إنشاء DACL Dim regDacl باسم Microsoft.Win32.Security.Dacl = _ New Microsoft.Win32.Security.Dacl() regDacl.AddAce(New AceAccessAllowed(Sids.Admins, _ AccessType.SPECIFIC_RIGHTS_ALL أو _ AccessType.STANDARD_RIGHTS_ALL, _ AceFlags.CONTAINER_INHERIT_ ACE )) regDacl.AddAce(New AceAccessAllowed(New Sid(_userName), _ AccessType.GENERIC_READ, AceFlags.CONTAINER_INHERIT_ACE)) " افتح مفتاح التسجيل Dim hKey As IntPtr Dim rc As Integer = Win32.RegOpenKey(New IntPtr(_ (int) )Microsoft .Win32.RegistryHive.LocalMachine)، _ regKey، hKey) " تعيين DACL إلى مفتاح التسجيل إذا rc = Win32.SUCCESS ثم Dim sd As SecurityDescriptor = _ SecurityDescriptor.GetRegistryKeySecurity(hKey, _ SECURITY_INFORMATION.DACL_SECURITY_INFORMATION أو _ SECURITY_INFORMATION. GROUP_SECURITY_INFORMATION أو _ SECURITY_INFORMATION) sd.SetDacl(regDacl, false) sd.SetRegistryKeySecurity (hKey, _ SECURITY_INFORMATION.DACL_SECURITY_INFORMATION) Win32.RegCloseKey(hKey) End If.

الحماية الرئيسية عبر DPAPI

لقد قمنا بتقييد الوصول إلى المفتاح عن طريق تعيين قائمة التحكم بالوصول (ACL)، ولكن يتم تخزين المفتاح بنص عادي في السجل، أي في مكان ما في نظام الملفات. لذلك، نواجه مهمة تشفير المفتاح نفسه باستخدام DPAPI. من حيث المبدأ، يوفر DPAPI تشفيرًا متماثلًا بدون مفتاح باستخدام بيانات المستخدم أو ملف تعريف الكمبيوتر الذي تم تحميله حاليًا كمفتاح. (راجع DpapiCryptographer.vb للحصول على التعليمات البرمجية المصدر الكاملة لفئة غلاف DPAPI.)

في وضع المستخدم، يقوم DPAPI بإنشاء مفتاح استنادًا إلى ملف تعريف المستخدم الذي تم تحميله. إذا تم تشفير شيء ما في وضع USER DPAPI، فيمكن للمستخدم الذي لديه هذا الحساب فقط فك تشفير المعلومات المشفرة. في هذه الحالة، تحتاج إلى تحميل ملف تعريف لحساب آخر غير الحساب الافتراضي الذي تستخدمه مكونات COM+. بالإضافة إلى ذلك، لدعم التشفير وفك التشفير عبر أجهزة كمبيوتر مختلفة، يجب تمكين ملفات التعريف المتجولة ويجب على كافة العملاء استخدامها. قد تكون هذه مهمة صعبة بالنسبة للمسؤول.

يعني وضع DPAPI MACHINE أن أي رمز يتم تشغيله على الكمبيوتر لديه حق الوصول إلى مفتاح DPAPI وبالتالي يمكنه فك تشفير أي بيانات مشفرة في وضع MACHINE. نريد تقييد الوصول إلى المفتاح، ويسمح لنا DPAPI بتمرير امتداد فريد لإضافة إنتروبيا إضافية إلى جيل المفتاح. سنقوم بتخزين هذا الامتداد في السجل مع المفتاح المشفر وسنستخدم قائمة التحكم بالوصول (ACL) لتقييد الوصول إلى الامتداد على نفس المستخدمين مثل المفتاح. هذا ليس الحل الأمثل. قد ترغب في تخزين ملحق DPAPI في مكان آخر. لمهاجمة الحل الذي نقدمه، تحتاج إلى تشغيل التعليمات البرمجية على الكمبيوتر، والوصول إلى مفتاح التسجيل المحمي بـ ACL، وتكون قادرًا على الاتصال بـ DPAPI، وتمرير الامتداد المسروق، لفك تشفير المفتاح. وبالنظر إلى أن مثل هذا الهجوم من غير المرجح أن يكون ممكنا، يمكن اعتبار الخطر معقولا. في التين. يوضح الشكل 2 كيف تبدو CryptoUtility في سياق COM+ وتطبيق العميل والأنظمة الفرعية المحيطة بـ CryptoUtility - DPAPI والتسجيل.

المصادقة المتبادلة والتعتيم الرئيسي

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

من ناحية، فإن تخزين المفتاح في السجل، وتشفيره وحمايته باستخدام قائمة التحكم بالوصول (ACL)، ليس بالأمر السيئ: فأنت تعرف مكان تخزين المفتاح، وكيفية حمايته، وما يلزم لسرقته. من ناحية أخرى، من السهل اكتشاف المفتاح، وإذا تغلب المهاجم على جميع الحواجز وسرق المفتاح، فسيكون لديه حق الوصول الكامل إلى البيانات المشفرة.

بالنسبة لأحد التطبيقات التي تستخدم CryptoUtility، قررنا إضافة مستوى آخر من تخزين المفاتيح - تطبيق العميل نفسه. ويستخدم تلك الأحمال الزائدة التي تقبل مفتاحًا جزئيًا. يتم تخزين نصف المفتاح في التطبيق، ويتم وضع النصف الآخر في السجل بواسطة CryptoUtility. يقوم التطبيق "بإخفاء" نصف المفتاح الخاص به عن طريق إخفائه بعدة طرق: استخدام أسلوب غير ضار وأسماء التعداد، وسلاسل ملفات الموارد بأسماء بسيطة، والعمليات الرياضية البسيطة، وما إلى ذلك.

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

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

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

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

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

حماية تطبيق التشفير نفسه

لقد أخذنا في الاعتبار مستويين من الحماية: حماية التشفير للبيانات الخاصة نفسها باستخدام خوارزمية Rijndael وحماية مفتاح هذه البيانات استنادًا إلى ACL وDPAPI. ولكن هناك طبقة ثالثة تحتاج إلى الحماية - تطبيق CryptoUtility نفسه!

إن تخزين المفتاح بالكامل في السجل، على وجه الخصوص، يعني أن أي تجميع مرخص له بالوصول إلى تجميع Crypto يمكنه استخدام أساليب التشفير/فك التشفير الخاصة به دون تحديد هويات إضافية. لذلك، يكون المستويان السابقان عديمي الفائدة إذا تمكن متصل مجهول من الاتصال بـ CryptoUtility لفك تشفير المفتاح.

لتجنب ذلك، يمكننا استخدام سمة LinkDemand الخاصة بنموذج أمان الوصول إلى التعليمات البرمجية (CAS) الخاص بنموذج StrongNameIdentityPermission (SNIP). تسمح لنا أداة CAS التصريحية هذه بوضع علامة على طريقة أو فئة بسمة تحتوي على المفتاح العام للتجميعات التي لها الحق في استدعاء تجميعنا. على سبيل المثال:

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

ومع ذلك، فإن هذا النهج لديه نقاط ضعف. تتمثل نقطة الضعف الرئيسية في SNIP LinkDemand في أن المستخدم الذي يتمتع بامتيازات كافية يمكنه بسهولة التأكد من اجتياز اختبارات الأمان من هذا النوع بنجاح، على سبيل المثال، عن طريق تغيير إعدادات أمان .NET Framework من خلال CASPOL (سياسة أمان الوصول إلى التعليمات البرمجية). تناول Keith Brown هذه المشكلات في عموده الصادر في أبريل 2004 بالإضافة إلى ذلك، سوف يفشل هذا الأسلوب إذا تم اختراق ملف SNK الخاص بك. يمكن أن يحدث هذا، على سبيل المثال، نتيجة لهجوم داخلي من قبل شخص ما في مجموعتك أو قريب من مجموعتك لديه حق الوصول إلى الملفات الرئيسية للأسماء القوية.

وأخيرا وليس آخرا. يحتوي هذا النهج على نقطة ضعف أخرى يمكن التنبؤ بها، ولكنها في نفس الوقت غير متوقعة إلى حد ما: COM. نظرًا لأن COM لا يدعم مفهوم الأسماء القوية، فإن COM لا يقبل السمة StrongNameIdentityPermission LinkDemand.

حماية كوم

لا يتبع COM قواعد .NET CAS. إذا قمنا بتثبيت CryptoUtility كتطبيق COM+، فسيتم الوصول إليه عن طريق COM تمامًا مثل أي مكون COM آخر منتشر على الكمبيوتر. وهذا يعني أنه يمكن اختراق نظام الأمان الذي تم تصميمه بعناية بالكامل باستخدام أبسط كود VBScript مكون من أربعة أسطر فقط:

تعيين التشفير = CreateObject("CryptoUtility.Crypto") الأصلي = "هذه هي الرسالة السرية." cipher = crypto.Encrypt("ourApp"، أصلي) واضح = crypto.Decrypt("ourApp"، تشفير)

ولكن لم نفقد كل شيء. يحتوي COM على حماية قوية تم اختبارها عبر الزمن ضد الوصول غير المصرح به. لتقييد الوصول إلى مستدعي COM، يجب عليك تمكين ترخيص COM+ للحزمة، كما هو موضح في الشكل 1. 2 والتين. 3.

CryptoUtility يتكون من ستة فئات. تحتوي الفئة الرئيسية، Crypto، فقط على واجهة برمجة التطبيقات (API) التي يمكن الوصول إليها خارجيًا من خلال واجهة ICrypto الخاصة بها. نظرًا لأن CryptoUtility عبارة عن ServicedComponent يعمل في COM+، فقد اتبعنا أفضل الممارسات في تطويره، بما في ذلك تنفيذ الواجهة بشكل صريح. تستخدم فئة Crypto عدة فئات داخلية مساعدة تقوم بالتشفير الفعلي. هذه هي الفئات SymmetricCryptographer، وDpapiCryptographer، وHasher (للتجزئة ومقارنة التجزئة) وفئة مساعدة لقراءة السلاسل من ملف الموارد.

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

ثانيا. المتطلبات والقواعد العامة لتنسيق الأوراق البحثية.

ثانيا. متطلبات هيكل البرنامج التعليمي للتعليم ما قبل المدرسة وحجمه

ثالثا. متطلبات نتائج إتقان محتوى التخصص

رابعا. المتطلبات الموحدة لاستخدام وحفظ الكتب المدرسية للطلاب وممثليهم القانونيين

خامساً: متطلبات إعداد وتنفيذ الأعمال التنافسية

عادةً ما يتم أخذ هجمات التشفير التالية في الاعتبار عند تشفير المفتاح السري.

هجوم النص المشفر

هجوم نص عادي معروف

تم اختيار هجوم نص عادي

متطلبات:

1. يجب أن يكون عدد المفاتيح الصالحة المحتملة كبيرًا بشكل غير شامل.

يأتي هذا المطلب مباشرة من وجود طريقة تافهة للقوة الغاشمة لتحليل الشفرات. إن عدم المبالغة في البيانات الأساسية هو الشرط الأكثر سهولة في تحقيقه. في الواقع، على سبيل المثال، إذا تم تثبيت مفتاح على مفتاحين مقاس 32´32، فإن العدد الإجمالي للمفاتيح المحتملة يصبح /32!/ = 6.92 ´10 70.

إذا حاولت 10 6 مفاتيح كل ثانية (في الواقع، لا تحتاج إلى تغيير المفاتيح فحسب، بل تحتاج أيضًا إلى التحقق من معنى الرسالة التي تم فك تشفيرها في كل منها)، فإن البحث في جميع المفاتيح سيكون تقريبًا 2.19 × 10 57 عامًا وسيكون متوسط ​​وقت البحث أقل مرتين. ومن الواضح أنه حتى لو قمنا بزيادة السرعة بمقدار عشرة أوامر من حيث الحجم، فسوف نحصل على وقت بحث طويل بشكل لا يصدق. إذا كان طول المفتاح 256 بت، فإن العدد الإجمالي للمفاتيح هو 2,256 = 1.16´10 77، وسيكون إجمالي وقت البحث، عند تجربة 10 6 مفاتيح في الثانية، 3.67 * 10 63 سنة. التقدم في مجال زيادة سرعة الكمبيوتر، على سبيل المثال، بمقدار 3 أوامر من حيث الحجم، أي الانتقال إلى اختبار 10 9 مفاتيح في الثانية، يمكن تعويضه بإضافة 10 بتات رئيسية.

ومن الواضح أيضًا أن استخدام، على سبيل المثال، 10 9 مجموعات من أجهزة الكمبيوتر بدلاً من جهاز كمبيوتر واحد لتحليل الشفرات، وهو ما يتجاوز بشكل كبير عدد جميع أجهزة الكمبيوتر المتوفرة على وجه الأرض، لن يؤثر على الاستنتاج العام بأن البيانات الأساسية ليست شاملة.

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

2. يجب استبعاد إحصائيات الرسائل إلى حد كبير من إحصائيات التشفير.

دعونا نشرح بمثال بسيط كيف أن الفشل في تلبية هذا المطلب يمكن أن يسمح بفك تشفير الرسالة ببساطة. دعونا نستخدم تشفير الاستبدال الخامل، الذي يحتوي على 32 للأبجدية الروسية! = 2.63´10 35 مفتاحًا محتملًا. ومع ذلك، إذا قمت بحساب ترددات ظهور الحروف المختلفة في التشفير ومقارنتها بجدول احتمالات الحروف في اللغة الروسية، فمن خلال مصادفتها يمكنك تحديد أحرف الرسالة التي تتوافق مع أحرف التشفير، ذلك هو فك تشفير التشفير في وقت قصير دون معرفة المفتاح.

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

3. يجب الحفاظ على عدم إمكانية فك التشفير العملي لنظام التشفير حتى في حالة معرفة بعض أجزاء الرسالة الواضحة المرسلة المقابلة للتشفير المستلم.

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

تؤدي الحاجة إلى تلبية المتطلب الثاني وخاصة المطلب الثالث إلى تغييرات كبيرة في هيكل جهاز التشفير.

دعونا ندرج عددًا من المتطلبات التي لا ترتبط بشكل مباشر بتعريف PNDSH، ومع ذلك، فقط في حالة استيفاءها، يمكن تسمية معدات التشفير، بالمعنى الحديث، بمعدات ذات قوة مضمونة.

4. القضاء على "اقرأ مرة أخرى".

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

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

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

1. توفير المتطلبات الخاصة.

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

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

| | | | | 6 | |