2011-01-31 20 views
6

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

  1. "मेरा ई-शॉप" किसी तीसरे पक्ष पर एक कंपनी "प्रमाणित" किए जाने की आवश्यकता के रूप में सीए। इसका मतलब है कि मुझे उस सीए में किसी प्रकार की 1 साल की सदस्यता खरीदने की ज़रूरत है, और फिर, वे अपने सिस्टम पर "माई ई-शॉप" पंजीकृत करेंगे और मुझे प्रमाणपत्र जैसे कुछ सामान और अद्वितीय सार्वजनिक और निजी कुंजी की एक जोड़ी जारी करेंगे। क्या मुझे कुछ प्रमाणपत्र-फ़ाइल मिल जाएगी?

  2. जारी प्रमाणपत्र मेरी जानकारी और सार्वजनिक कुंजी से भरा हुआ है और मेरे वेबसर्वर पर कुछ फ़ाइल में संग्रहीत है। प्रमाण पत्र सत्यापित करता है कि "मेरी ई-दुकान" चोरों का एक ब्यूरो नहीं है।

  3. हर बार जब उपयोगकर्ता अपने ब्राउज़र "चुपचाप" के माध्यम से "मेरी ई-दुकान" तक पहुंचते हैं तो "चुपचाप" सीए में पंजीकृत एक के साथ "माई ई-शॉप" के प्रस्तुत प्रमाण पत्र की जांच करता है।

    1. उपयोगकर्ताओं के बारे में क्या? Https के माध्यम से "मेरी ई-दुकान" दर्ज करते समय उनके ब्राउज़र स्थानीय सार्वजनिक + निजी कुंजी उत्पन्न करते हैं?
  4. कुछ उपयोगकर्ता में प्रवेश करती है के माध्यम से https निम्न होता है "मेरा ई-शॉप": "मेरा ई-शॉप" (वेब ​​सर्वर) उपयोगकर्ता की सार्वजनिक कुंजी (PK1) हो जाता है। सर्वर चुपचाप उपयोगकर्ता को "माई ई-शॉप" का प्रमाणपत्र प्रस्तुत करता है, इसलिए उपयोगकर्ताओं को "माई ई-शॉप" की सार्वजनिक कुंजी (पीके 2) मिलती है। कुछ चुप जांच के बाद उपयोगकर्ता के ब्राउजर को प्रस्तुत प्रमाण पत्र मान्य करता है और एक सुरक्षित पाइप स्थापित किया जाता है।

  5. जब कोई उपयोगकर्ता सुरक्षित पाइप के माध्यम से अनुरोध भेजता है तो अनुरोध "मेरी ई-दुकान" की सार्वजनिक कुंजी से एन्क्रिप्ट किया जाता है। फिर, वेब सर्वर अनुरोध को अपनी निजी कुंजी से डिक्रिप्ट करता है। फिर, वेब सर्वर उपयोगकर्ता की सार्वजनिक कुंजी के साथ एन्क्रिप्टेड प्रतिक्रिया भेजता है। अंत में, उपयोगकर्ता का ब्राउज़र उसकी निजी कुंजी के साथ प्रतिक्रिया को अस्वीकार करता है।

+0

आपको वेबमास्टर्स पर बेहतर प्रतिक्रिया मिलेगी। स्टैक एक्सचेंज या सिक्योरिटी। स्टैक एक्सचेंज ... इसके अलावा, कुछ के लिए [एसएसएल विकिपीडिया पेज] (http://en.wikipedia.org/wiki/Secure_Sockets_Layer) देखें अधिक पढ़ना ... – ircmaxell

+0

धन्यवाद, मैं वहां अपनी किस्मत आजमाऊंगा :) – Centurion

उत्तर

3

प्रश्न द्वारा इन सवाल उठाते हुए:

(1) "मेरा ई-शॉप" एक कंपनी जा किसी तीसरे पक्ष सीए पर "प्रमाणित" के रूप में करने की जरूरत है इसका मतलब है कि मुझे लगता है कि सीए 1 वर्ष सदस्यता के कुछ प्रकार के खरीदने की जरूरत है, और तो, वे अपने सिस्टम पर दर्ज किए जाएंगे "मेरा ई-शॉप ' और एक प्रमाण पत्र और अद्वितीय की एक जोड़ी की तरह मुझे कुछ सामान जारी सार्वजनिक और निजी कुंजी। क्या मुझे कुछ प्रमाणपत्र-फ़ाइल मिलेगी?

हां। इसके अलावा, यह सीए से सीए में भिन्न होता है - कुछ सीएएस, एक साल की सदस्यता और वैध क्रेडिट कार्ड पर्याप्त है (पाने के लिए मुश्किल नहीं है, भले ही आप जीवों का बैंड बनें), कुछ सीए को कागजी कार्य की एक निश्चित मात्रा की आवश्यकता होती है यह सत्यापित करने के लिए कि आप कौन हैं जो आप कहते हैं। एक सीए उतना ही अच्छा है जितना ग्राहक की सत्यापन प्रक्रिया है, इसलिए आम तौर पर अधिक कठिन प्रक्रिया, बेहतर (और अधिक महंगी) सीए।

  • एक सार्वजनिक/निजी कुंजी युग्म:

    जब आप अपने पैसे का भुगतान किया और अपनी कागजी कार्रवाई किया है, तो आप और सीए कम से कम 2 बातें उत्पन्न होगा। अक्सर यह आपके द्वारा उत्पन्न होता है, सीए द्वारा नहीं। आपने अपनी मुख्य जोड़ी को कैसे बनाया और संग्रहीत किया है, इसकी गुणवत्ता यह निर्धारित करने में एक कारक है कि आपकी वेबसाइट पर कितनी अधिक इकाई भरोसा कर सकती है। आम तौर पर, पहचान प्रमाण पत्र (जैसे SSL सर्वर certs) के लिए ग्राहक (मेरा ई-शॉप) कुंजी उत्पन्न करने का एक अच्छा विचार है।

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

आप वापस पाने के दो में से एक:

  • सिर्फ प्रमाणपत्र (आप अपने खुद के कुंजी युग्म उत्पन्न करता है, तो)
  • प्रमाणपत्र और कुंजी युग्म - अगर सीए के लिए कुंजी युग्म उत्पन्न आप

(2) जारी किए गए प्रमाण पत्र मेरे जानकारी और सार्वजनिक कुंजी से भरा है और मेरी वेब सर्वर पर में कुछ फ़ाइल संग्रहित है। प्रमाण पत्र सत्यापित करता है कि "मेरा ई-शॉप" चोरों का एक ब्यूरो नहीं है।

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

(3) हर बार जब उन "https" के पास उनके ब्राउज़र के माध्यम से "मेरा ई-शॉप" का उपयोग "चुपचाप" प्रस्तुत एक है कि सीए पंजीकृत किया गया है के साथ "मेरा ई-शॉप" का प्रमाण पत्र की जांच करता है ।

"चुप" की कुछ परिभाषा के लिए। एक आधारभूत ब्राउज़र की जाँच करता है कि प्रमाण पत्र: - वर्तमान में मान्य है - एक सीए द्वारा हस्ताक्षर किए है कि ब्राउज़र भरोसा करता है (या यह या तो पहुँच से इनकार करते हैं या आप एक कष्टप्रद पॉप-अप देता है)

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

(4) कुछ उपयोगकर्ता में प्रवेश करती है "मेरा ई-शॉप" https के माध्यम से निम्न होता है: "मेरे ई-शॉप" (वेब ​​सर्वर) उपयोगकर्ता की सार्वजनिक कुंजी (PK1) हो जाता है। सर्वर चुपचाप उपयोगकर्ता को "मेरा ई-शॉप" प्रमाण पत्र प्रस्तुत करता है, इसलिए उपयोगकर्ताओं को "मेरी ई-शॉप" की सार्वजनिक कुंजी (पीके 2) मिलती है।कुछ चुप उपयोगकर्ता के ब्राउज़र की जांच प्रस्तुत प्रमाणित मान्य करता है और एक सुरक्षित पाइप स्थापित किया गया है।

  • उपयोगकर्ताओं के बारे में क्या? Https के माध्यम से "मेरी ई-दुकान" दर्ज करते समय उनके ब्राउज़र स्थानीय सार्वजनिक + निजी कुंजी उत्पन्न करते हैं?

ठीक है - सामान यहां रेल से बाहर जा रहा है।

विवरण के लिए, एसएसएल प्रोटोकॉल की जांच करें - हैंडशेक अनुभाग आपको कठिन तथ्य देगा।

ब्राउज़र और वेबसर्वर आगे और आगे की जानकारी पास करता है जो उन्हें सत्र एन्क्रिप्शन कुंजी बनाने देता है। ब्राउज़र सत्र शुरू करने के लिए उपयोग की जाने वाली कुछ प्रारंभिक सामग्री उत्पन्न करता है, लेकिन यह "उपयोगकर्ता की सार्वजनिक कुंजी (पीके 1)" नहीं है। उपयोगकर्ता को पीकेआई प्रमाण-पत्रों की आवश्यकता नहीं है, सर्वर को क्लाइंट प्रमाणीकरण के लिए कॉन्फ़िगर किया गया है। नियमित रूप से मिल मिल माई ई-शॉप, सर्वर के पास पीकेआई क्रेडेंशियल है, ब्राउज़र केवल एक सत्र के लिए फ्लाई पर कुछ महत्वपूर्ण सामग्री उत्पन्न कर रहा है। सर्वर को बिल्कुल पता नहीं है कि ब्राउज़र उपयोगकर्ता कौन है, एसएसएल-वार - उपयोगकर्ता की सभी पहचान पासवर्ड से या एप्लिकेशन स्तर पर कुछ और होती है।

नोट: यह एक नियमित वाणिज्यिक लेनदेन के लिए है। जोखिम जितना अधिक होगा, सुरक्षा उतनी ही अधिक होगी। उच्च जोखिम लेनदेन अक्सर ग्राहक प्रमाणीकरण की आवश्यकता होती है।

(5) एक उपयोगकर्ता अनुरोधों सुरक्षित पाइप के माध्यम से एक अनुरोध भेजता है "मेरे ई-शॉप" की सार्वजनिक कुंजी के साथ एन्क्रिप्टेड है। फिर, वेब सर्वर को अपनी निजी कुंजी के साथ अनुरोध को अस्वीकार करता है। फिर, वेब सर्वर उपयोगकर्ता की उपयोगकर्ता की सार्वजनिक कुंजी के साथ एन्क्रिप्टेड प्रतिक्रिया भेजता है। अंत में, उपयोगकर्ता का ब्राउज़र निजी कुंजी के साथ प्रतिक्रिया को अस्वीकार करता है।

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

यह गुप्त कुंजी सममित है (बिल्कुल कौन सा एल्गोरिदम हस्तशिल्प का हिस्सा है) और शेष सत्र के लिए उपयोग किया जाता है।

+0

चीजें अब और अधिक स्पष्ट हैं :) व्यापक उत्तर bethlakshmi के लिए धन्यवाद, शुभकामनाएँ :) – Centurion

0

बिंदु 3 के बारे में:

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

और हाँ ब्राउज़र उत्पन्न करना होगा एक "अविश्वसनीय" कुंजी जोड़ी, सामान्य परिस्थितियों में एक मानक उपयोगकर्ता अपना स्वयं का प्रमाण पत्र नहीं उत्पन्न करेगा।

बिंदु 5 के बारे में:

इसके अलावा इस पूरी तरह से सच नहीं है। एसिंक्रोनस एन्क्रिप्शन की गणना के लिए बहुत अधिक समय की आवश्यकता होती है। इसलिए आरएसए एल्गोरिदम का उपयोग तेजी से सिंक्रोनस एन्क्रिप्शन मानकों (यानी एईएस, 3 टीईएस) के लिए चाबियों का आदान-प्रदान करने के लिए किया जाता है।

+0

बिंदु 5 के जवाब के बारे में: कृपया स्पष्ट करें "आरएसए एल्गोरिदम का उपयोग केवल कुंजी का आदान-प्रदान करने के लिए किया जाता है"। मेरा मतलब है, अगर किसी सर्वर और क्लाइंट के बीच "स्निफ़फर" है, तो, प्रत्येक अनुरोध/प्रतिक्रिया के लिए कोई एन्क्रिप्शन/डिक्रिप्शन नहीं होने पर जानकारी का आदान-प्रदान कैसे सुरक्षित हो सकता है? – Centurion

+0

सुनिश्चित करें कि एक एन्क्रिप्शन प्रक्रिया है; मेरा मतलब यह है कि आरएसए सिस्टम का उपयोग करके पूरा डेटा एन्क्रिप्ट नहीं किया गया है, क्योंकि यह बहुत अक्षम है। इसके बजाय प्रमाणपत्रों की सार्वजनिक और निजी कुंजी का उपयोग यादृच्छिक सिंक्रोनस कुंजी (एईएस जैसे एक्सओआर ऑपरेशंस के साथ काम करने) को स्थानांतरित करने के लिए किया जाता है और इन चाबियों के साथ वास्तविक सामग्री एन्क्रिप्टेड हो जाती है। –

+0

डबल एन्क्रिप्शन/डिक्रिप्शन की तरह लगता है :) इसलिए सार्वजनिक और निजी कुंजी का उपयोग केवल कुछ यादृच्छिक सिंक्रोनस कुंजी को एन्क्रिप्ट करने/डिक्रिप्ट करने के लिए किया जाता है।इसके अलावा, पूरे सत्र के लिए या प्रत्येक अनुरोध के लिए यादृच्छिक सिंक्रोनस कुंजी उत्पन्न होती है? यदि पूरे सत्र के लिए, मुझे लगता है कि एक उपयोगकर्ता ब्राउज़र उस यादृच्छिक syn उत्पन्न करने के लिए ज़िम्मेदार है। पहले अनुरोध के दौरान कुंजी? – Centurion

1

आपके चरण कुछ अलग-अलग स्तरों पर गलत हैं। मुझे उम्मीद है कि, स्पष्ट रूप से उन्हें स्पष्ट करें।

  1. आपकी साइट पर भरोसा किया तीसरे पक्ष के सीए (Verisign, आदि) एक से एक SSL प्रमाणपत्र की जरूरत है। आपको इसे खरीदने की ज़रूरत होगी। आप सार्वजनिक/निजी कुंजी जोड़ी उत्पन्न करेंगे, उन्हें अपनी सार्वजनिक कुंजी प्रदान करें (यह प्रमाणपत्र अनुरोध का हिस्सा है) और वे प्रमाणपत्र उत्पन्न करेंगे।

  2. प्रमाणपत्र में आपकी साइट का डोमेन नाम, आपकी सार्वजनिक कुंजी और कुछ अन्य अतिरिक्त जानकारी शामिल है। यह कुछ भी सत्यापित नहीं करता है, विशेष रूप से यह नहीं कि आपकी साइट "चोरों का एक ब्यूरो" नहीं है। यह आमतौर पर प्रमाणित करता है कि आप उस डोमेन नाम के स्वामी हैं जिसके लिए आप प्रमाणपत्र का अनुरोध कर रहे हैं। इसका मतलब यह नहीं है कि आपकी साइट किसी भी माध्यम से भरोसेमंद है।

  3. जब कोई उपयोगकर्ता HTTPS के माध्यम से आपकी साइट तक पहुंचता है, आपका सर्वर प्रमाण पत्र को क्लाइंट के ब्राउज़र पर भेज देगा। क्लाइंट आपके प्रमाणपत्र को प्रमाणित करने के लिए सीए के साथ संवाद नहीं करता है।

3.1। आम तौर पर, अंतिम उपयोगकर्ताओं (ग्राहकों, ग्राहकों) को अपने स्वयं के प्रमाणपत्र और निजी कुंजी की आवश्यकता नहीं होती है। इसे पारस्परिक रूप से प्रमाणित एसएसएल कहा जाता है, और इसमें दोनों पार्टियां शामिल हैं (आपके ग्राहक और आपकी साइट) प्रमाणपत्र हैं। यह शायद ही कभी (यदि कभी) ई-कॉमर्स साइटों में उपयोग किया जाता है।

  1. जब कोई उपयोगकर्ता HTTPS के माध्यम से आपकी साइट तक पहुंचता है, तो आपका सर्वर क्लाइंट ब्राउज़र में प्रमाण पत्र भेजता है। ग्राहक इसका उपयोग एसएसएल हैंडशेक करने के लिए करेगा। ब्राउज़र और आपकी साइट के बीच यह हैंडशेक सुरक्षित सुरंग स्थापित करता है। हैंडशेक प्रोटोकॉल के विनिर्देश आपको आवश्यकतानुसार अधिक तकनीकी हैं।

  2. जब एसएसएल सुरंग पर सर्वर पर एक अनुरोध भेजा जाता है, तो सर्वर इसे उसी तरह से संभालता है जैसा कि यह कोई अन्य अनुरोध होगा। केवल अंतर यह है कि आपके ग्राहकों और आपके सर्वर के बीच संचार एन्क्रिप्ट किया गया है। आपका वेबसर्वर अनुरोध से डेटा के डिक्रिप्शन को संभालने और प्रसंस्करण के लिए इसे अपने वेबसर्वर पर पेश करेगा। इसी प्रकार, प्रतिक्रिया डेटा क्लाइंट को वापस एन्क्रिप्टेड रूप में एसएसएल सुरंग के माध्यम से वापस कर दिया जाता है।

बेहतर?

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