2010-06-14 10 views
16

मेरे पास एक ऐसा एप्लिकेशन है जहां मुझे यूडीपी का उपयोग करके नेटवर्क के माध्यम से प्रति सेकंड कई छोटे डेटा भेजना पड़ता है। एप्लिकेशन को वास्तविक समय में डेटा भेजने की आवश्यकता है (कोई प्रतीक्षा नहीं)। मैं इन आंकड़ों को एन्क्रिप्ट करना चाहता हूं और बीमा कर रहा हूं कि मैं जो कर रहा हूं वह जितना संभव हो उतना सुरक्षित है।निरंतर/छोटे यूडीपी डेटा को एन्क्रिप्ट करने के लिए सर्वोत्तम अभ्यास

चूंकि मैं यूडीपी का उपयोग कर रहा हूं, इसलिए एसएसएल/टीएलएस का उपयोग करने का कोई तरीका नहीं है, इसलिए मुझे प्रत्येक पैकेट को अकेले एन्क्रिप्ट करना होगा क्योंकि प्रोटोकॉल कनेक्शन रहित/अविश्वसनीय/अनियमित है।

अभी, मैं उपयोगकर्ता से पासफ्रेज से व्युत्पन्न 128-बिट कुंजी का उपयोग कर रहा हूं, और सीईसी मोड में एईएस (एईएस-सीबीसी का उपयोग कर पीबीई) का उपयोग कर रहा हूं। मैंने 128-बिट कुंजी प्राप्त करने के लिए पासफ्रेज़ के साथ एक यादृच्छिक नमक का उपयोग करने का निर्णय लिया (पासफ्रेज पर शब्दकोश हमले को रोकें), और निश्चित रूप से IVs (पैकेट के लिए सांख्यिकीय विश्लेषण को रोकने के लिए) का उपयोग करें।

हालांकि मैं कुछ चीजों के बारे में चिंतित हूँ: प्रत्येक पैकेट जो एन्क्रिप्टेड पैकेट में जाना जाता प्लेन टेक्स्ट हमले के लिए असुरक्षित (जो इसे और आसान बना का परिणाम देगा कर देगा (पैकेट प्रति पूर्णांक मूल्यों के एक जोड़े की तरह) डेटा की कम मात्रा में होती कुंजी को दरकिनार करने के लिए)। इसके अलावा, चूंकि एन्क्रिप्शन कुंजी पासफ्रेज़ से ली गई है, इससे कुंजी स्थान कम हो जाएगा (मुझे पता है कि नमक मदद करेगा, लेकिन मुझे नेटवर्क के माध्यम से नमक भेजना होगा और कोई भी इसे प्राप्त कर सकता है)। इन दो चीजों को देखते हुए, कोई भी भेजा गया डेटा स्नीफ और स्टोर कर सकता है, और कुंजी को क्रैक करने का प्रयास कर सकता है। यद्यपि इस प्रक्रिया में कुछ समय लग सकता है, एक बार जब कुंजी क्रैक हो जाती है तो सभी संग्रहीत डेटा डिक्रिप्ट हो जाएंगे, जो मेरे आवेदन के लिए एक वास्तविक समस्या होगी।

तो मेरा सवाल यह है कि कनेक्शन रहित प्रोटोकॉल (यूडीपी) का उपयोग करके निरंतर छोटे डेटा को भेजने/एन्क्रिप्ट करने के लिए सबसे अच्छा प्रथा क्या है? क्या मेरा तरीका यह करने का सबसे अच्छा तरीका है? ... प्रवाहित होती? ... Overkill?

कृपया ध्यान दें कि मैं 100% सुरक्षित समाधान नहीं मांग रहा हूं, क्योंकि ऐसी कोई चीज़ नहीं है।

+0

बस एक नोटिस के रूप में: आज (5.12.2014) के रूप में, स्पार्क कोर सर्वर (क्लाउड) के साथ संचार करते समय एईएस-128-सीबीसी का उपयोग कर रहा है। यह ~ 15bytes संदेश के साथ प्रत्येक 15 सेकंड में कम से कम एक बार सर्वर को पिंग करता है जो एन्क्रिप्शन के बाद 2 + 128bytes लेता है। जब उपयोगकर्ता अधिक डेटा भेजने/पुनः प्राप्त करने का निर्णय लेता है तो यह जल्दी से जमा हो जाता है (विशेष रूप से 3 जी पर)। –

उत्तर

12

आपके पास कई विकल्प हैं। आप डीटीएलएस का उपयोग कर सकते हैं, जो डेटाग्राम के लिए अनुकूलित टीएलएस का एक संस्करण है। यह RFC में निर्दिष्ट है और openssl लाइब्रेरी में कार्यान्वित किया गया है। आप आईकेई/आईपीएससी प्रोटोकॉल का भी उपयोग कर सकते हैं और आईपीसीईसी भाग के यूडीपी encapsulation का उपयोग कर सकते हैं। आमतौर पर आईपीएस स्तर ओएस स्तर पर उपलब्ध है। आप OpenVPN का भी उपयोग कर सकते हैं, जो मुख्य एक्सचेंज और मालिकाना यूडीपी-आधारित पैकेट एन्क्रिप्शन प्रोटोकॉल के लिए टीएलएस का संकर होना प्रतीत होता है।

+0

डीटीएलएस/आईपीएसईसी मेरी समस्या के लिए दिलचस्प प्रोटोकॉल हैं। वे मजबूत पीढ़ी को मजबूत बनाने में मदद कर सकते हैं लेकिन मुझे संदेह है कि वे छोटी डेटा समस्या के बारे में कुछ भी करेंगे, जिसे मुझे अपने आप संभालना चाहिए। मैं उन्हें और अधिक खोजूंगा। धन्यवाद – temp

+0

मैं बहुत स्पष्ट नहीं हूं और वास्तव में "छोटा डेटा" समस्या क्या है, लेकिन फिर भी एक और विकल्प एसआरटीपी प्रोटोकॉल, आरएफसी 3711 का उपयोग करना है। डेटा प्रबंधन के लिए प्रमुख प्रबंधन और एसआरटीपी के लिए डीटीएलएस (आरएफसी 5764) आईईटीएफ पसंद है सुरक्षित वीओआईपी के लिए, और इसमें कई छोटे फ्रेम आगे और आगे जा रहे हैं। –

+1

@temp "छोटी डेटा समस्या" क्या है? यदि आपके पैकेट इतने छोटे हैं कि वे एन्ट्रॉपी को सीमित करते हैं, तो सुरक्षा का समझौता करने का एकमात्र तरीका यह है कि यदि आपका सर्वर इस तरह से रिपोर्ट करता है कि हमलावर की जानकारी दे सकती है कि क्या यह सही मूल्य अनुमान लगाने में सफल रहा है या नहीं। इसका समाधान उन प्रतिक्रियाओं को कभी भी जारी नहीं करना है जो अविश्वसनीय ग्राहकों को उस तरह की जानकारी प्रदान करते हैं जब तक कि हर समय पर्याप्त इनपुट जमा न हो जाए। चाहे यह मुश्किल है या तुच्छ आपके पाठ्यक्रम पर निर्भर करता है। पैडिंग के अम्नोन के सुझाव भी काम करते हैं; थोड़ा और अपमानजनक। –

3

यदि आपकी समस्या यह है कि डेटा बहुत छोटा है, तो डेटा को यादृच्छिक बाइट्स के साथ विस्तारित करने के बारे में कैसे? यह अनुमान लगाने के लिए सादा पाठ को अधिक कठिन बना देगा।

+0

हाँ आप सही हैं। मैंने इसके बारे में सोचा लेकिन ऊपर इसका उल्लेख नहीं किया क्योंकि मैंने अभी तक इसे लागू नहीं किया है। मैं देखता हूं कि दूसरों ने क्या सुझाव दिया है। – temp

+0

मैं एन्क्रिप्शन के लिए नया हूं लेकिन शायद आप यादृच्छिक बाइट्स के * स्थान (ओं) * को यादृच्छिक बनाने के लिए कुछ रणनीति भी कर सकते हैं, और जब क्लाइंट पैकेट के डेटा को पढ़ता है तो यह आसानी से पता लगा सकता है कि कौन से बाइट्स को छोड़ना है, लेकिन शायद यह एन्क्रिप्टेड डेटा का विश्लेषण करने की कोशिश कर रहे बाहरी व्यक्ति की कठिनाई में वृद्धि होगी। – rsethc

0

यह प्रश्न थोड़ा पुराना है, लेकिन One Time Pad प्रकार के दृष्टिकोण का उपयोग करने के बारे में क्या? सर्वर से एक बार कुंजी को अपने क्लाइंट में प्रेषित करने के लिए आप एक सुरक्षित विश्वसनीय परिवहन तंत्र (जैसे HTTPS) का उपयोग कर सकते हैं। चाबियों के दो सेट हो सकते हैं - क्लाइंट से अलग होने के लिए, और सर्वर के लिए क्लाइंट के लिए एक। प्रत्येक डेटाग्राम में एक अनुक्रम संख्या (एक बार कुंजी की पहचान करने के लिए उपयोग की जाती है) और फिर एन्क्रिप्टेड संदेश शामिल होगा। चूंकि प्रत्येक कुंजी का उपयोग केवल एक डेटाग्राम के लिए किया जाता है, इसलिए आपको छोटी डेटा समस्या से अवगत नहीं होना चाहिए। उस ने कहा, मैं इस सामान पर एक विशेषज्ञ नहीं हूं, इसलिए इसे उपयोग करने से पहले इस विचार को निश्चित रूप से देखें ...

0

Ecdh कुंजी एक्सचेंज का उपयोग करें (क्लाइंट निजी कुंजी एन्क्रिप्ट करने के लिए पासवर्ड का उपयोग करें; क्लाइंट पर छोड़ दिया गया है) एक पासवर्ड का यह एक बहुत मजबूत कुंजी है।

एएस सीबीसी आपकी मदद नहीं करता है; संदेश बहुत कम हैं और आप रीप्ले हमलों को रोकना चाहते हैं। काउंटर के साथ अपने 64 बिट संदेश (दो पूर्णांक) को पैड करें (0 से शुरू) 64 बिट्स का अर्थ है 2^64 संदेश भेजे जा सकते हैं। ब्लॉक को दो बार एन्क्रिप्ट करें (एईएस ecb) और ई (के; एम | गिनती) | ई (के; ई (के; एम | गिनती) भेजें)। रिसीवर केवल एकात्मक रूप से बढ़ती गणना स्वीकार करता है जहां दूसरा ब्लॉक पहले की एन्क्रिप्शन है। ये 32 बाइट संदेश हैं जो एक udp पैकेट में ठीक फिट बैठते हैं।

यदि 2^64 संदेश बहुत छोटे हैं; देखें कि आपका संदेश छोटा हो सकता है (3 बाइट पूर्णांक का मतलब है कि काउंटर 80 बिट्स हो सकता है); या सीमा के बाद चरण 1 (कम से कम एक तरफ के लिए नई निजी कुंजी) पर जाएं (सीमा 2^64-2^32) सीमा तक।

+0

ए "कुछ सेकंड" का अर्थ है 2^64 पैकेट प्रभावी रूप से अनंत है। आपको कुंजी रीसेट नहीं करना पड़ेगा। –

संबंधित मुद्दे