ऐप्लिकेशन लेयर को एन्क्रिप्ट (सुरक्षित) करना

Standard Payments APIs, ऐप्लिकेशन लेयर के लिए एन्क्रिप्शन के लिए PGP या JWE में से किसी एक का इस्तेमाल करते हैं.

पीजीपी एन्क्रिप्शन

PGP, एन्क्रिप्शन, डिक्रिप्शन, और हस्ताक्षर करने के एल्गोरिदम का एक स्टैंडर्ड सेट है. यह क्रिप्टोग्राफ़िक निजता और पुष्टि की सुविधा देता है.

पे लोड को एन्क्रिप्ट (सुरक्षित) करने के लिए PGP का इस्तेमाल करते समय, पार्टनर को इन बातों का ध्यान रखना होगा:

• एक से ज़्यादा पीजीपी कुंजियों की मदद से पेलोड को एन्क्रिप्ट (सुरक्षित) और डिक्रिप्ट करना.
• एक से ज़्यादा PGP कुंजियों से पेलोड पर हस्ताक्षर करना.
• एक से ज़्यादा हस्ताक्षर वाले पेलोड की पुष्टि करना. इनमें से कोई भी हस्ताक्षर, Google की ओर से दी गई कुंजी का इस्तेमाल करके किया गया हस्ताक्षर हो सकता है.
• वेब के लिए सुरक्षित base64 कोड में बदले गए पेलोड को डिक्रिप्ट करना.

Google को दी गई पीजीपी सार्वजनिक कुंजियों में, एन्क्रिप्शन के लिए इस्तेमाल की गई सब-की होनी चाहिए. सबकुंजी की मदद से, प्राइमरी कुंजी को स्वतंत्र रूप से रोटेट किया जा सकता है. प्राइमरी पासकोड का इस्तेमाल, पहचान की पुष्टि करने के लिए किया जाता है. निजी कुंजियां, 2048 (या इससे ज़्यादा) बिट आरएसए कुंजियां होनी चाहिए. इनकी समयसीमा एक साल होनी चाहिए और ज़्यादा से ज़्यादा दो साल होनी चाहिए.

डेवलपमेंट शुरू करने से पहले, आपको Google के साथ पीजीपी कुंजियां एक्सचेंज करनी होंगी. इस चरण में, आपको PGP सार्वजनिक-निजी पासकोड का जोड़ा जनरेट करना होता है. साथ ही, Google को सार्वजनिक पासकोड देना होता है. इसके बाद, Google से आपको सार्वजनिक पासकोड मिलता है. डेवलपमेंट के दौरान, आपको सिर्फ़ सैंडबॉक्स कुंजियां एक्सचेंज करनी होंगी. इनका इस्तेमाल डेवलपमेंट और टेस्टिंग के लिए किया जाता है. ये कुंजियां, प्रोडक्शन के बाहर इस्तेमाल की जाती हैं. प्रोडक्शन टेस्टिंग और लॉन्च से पहले, आपको प्रोडक्शन की कुंजियों को फिर से बदलना होगा.

नई PGP कुंजी जनरेट करना

मान लें कि आपके सिस्टम पाथ में GPG बाइनरी है. ऐसे में, नई कुंजी जोड़ी बनाने के लिए, यहां दी गई POSIX कमांड का इस्तेमाल किया जा सकता है.

$ gpg --full-generate-key

जब आपसे पूछा जाए, तब कम से कम 2048 बिट के एन्ट्रोपी वाली आरएसए कुंजी चुनें. साथ ही, इसकी समयसीमा एक से दो साल होनी चाहिए. इस कमांड से, एक प्राइमरी कुंजी (SC के तौर पर लेबल की गई है, जिसका मतलब 'S'igning और 'C'ertificate जनरेशन है) और एक सबकुंजी (E के तौर पर लेबल की गई है, जिसका मतलब 'E'ncryption है), दोनों बननी चाहिए.

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाना

कुंजी रोटेशन के दौरान बिना किसी रुकावट के सेवा जारी रखने के लिए, सिस्टम में पार्टनर और Google, दोनों के लिए एक से ज़्यादा चालू PGP कुंजियों का इस्तेमाल किया जा सकता है.

• रोटेशन के दौरान, पेलोड पर पुरानी और नई, दोनों कुंजियों से हस्ताक्षर किए जा सकते हैं. Google, हस्ताक्षर की पुष्टि इन चीज़ों के आधार पर करेगा: Google के पास मौजूद कोई भी चालू सार्वजनिक कुंजी.

• Google के सार्वजनिक पासकोड बदलने के दौरान, पेलोड को Google के पुराने और नए, दोनों सार्वजनिक पासकोड से एन्क्रिप्ट (सुरक्षित) किया जा सकता है. Google, किसी भी पासकोड से डिक्रिप्ट कर सकता है.

• मैसेज में मौजूद PGP कुंजी आईडी की मदद से, कुंजी की पहचान अपने-आप हो जाती है. इससे पेलोड वर्शन फ़ील्ड या स्विचओवर के लिए तय किए गए समय की ज़रूरत नहीं पड़ती.

PGP लाइब्रेरी कॉन्फ़िगरेशन

पेलोड भेजना

1. हस्ताक्षर करते समय, डाइजेस्ट एल्गोरिदम के तौर पर SHA384 का इस्तेमाल करें. SHA1 या MD5 का इस्तेमाल न करें
2. एन्क्रिप्ट (सुरक्षित) करते समय, आपको सिमेट्रिक एन्क्रिप्शन एल्गोरिदम के तौर पर AES256 का इस्तेमाल करना चाहिए. CAST5 या IDEA का इस्तेमाल न करें
3. मैसेज को एन्क्रिप्ट (सुरक्षित) करते समय या उन पर हस्ताक्षर करते समय, पक्का करें कि आपने सही सब-की चुनी हो. हस्ताक्षर करने के लिए CAN_SIGN की का इस्तेमाल करें और एन्क्रिप्ट (सुरक्षित) करने के लिए ENCRYPT_COMMS/ENCRYPT_STORAGE की का इस्तेमाल करें

पेलोड पाना

1. किसी पेलोड की पुष्टि करते समय, पक्का करें कि आपकी लाइब्रेरी, SHA384 जैसे आधुनिक हैश एल्गोरिदम के साथ काम करती हो. Google, 14 मई, 2023 से सभी नई कुंजियों के लिए इसका इस्तेमाल शुरू कर देगा.
2. किसी पेलोड को डिक्रिप्ट करते समय, पक्का करें कि आपकी लाइब्रेरी, AES256 जैसे आधुनिक सिमेट्रिक एन्क्रिप्शन एल्गोरिदम के साथ काम करती हो. Google, 14 मई, 2023 से सभी नए कुंजियों के लिए इसका इस्तेमाल शुरू कर देगा.

GPG पेलोड एन्क्रिप्शन का उदाहरण

यहां दी गई कमांड, GPG का इस्तेमाल करते समय सुरक्षित विकल्प चुनने का एक उदाहरण है. यह कार्रवाई भरोसेमंद एनवायरमेंट में की जानी चाहिए. यहां लोगों के पास निजी कुंजियों या संवेदनशील इनपुट फ़ाइलों का ऐक्सेस नहीं होना चाहिए.

gpg --output signed-and-encrypted.pgp \
  --sign --digest-algo SHA384 \
  --encrypt --cipher-algo AES256 \
  --armor \
  --recipient {key_id} \
  input.txt

GPG, बंडल में से सही कुंजी को अपने-आप चुन लेगा. ऐसा हर उस ऑपरेशन के लिए होगा जिसे करने के लिए आपने कहा है.

JWS पर हस्ताक्षर करने के साथ JWE एन्क्रिप्शन

JSON वेब एन्क्रिप्शन (JWE), ऐप्लिकेशन लेवल पर कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने के लिए rfc7516 में तय किया गया एक स्टैंडर्ड है. JSON वेब सिग्नेचर (JWS), ऐप्लिकेशन लेवल पर कॉन्टेंट पर हस्ताक्षर करने के लिए rfc7515 में तय किया गया एक स्टैंडर्ड है.

अनुरोध और जवाब, JWE टोकन होंगे. इन्हें एसिमेट्रिक (सार्वजनिक कुंजी) एन्क्रिप्शन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया जाएगा. साथ ही, "कॉम्पैक्ट सीरियलाइज़ेशन" विकल्प का इस्तेमाल किया जाएगा. JWE टोकन में, हस्ताक्षर किया गया पेलोड, JWS टोकन के तौर पर शामिल होगा. JWS में भी असिमेट्रिक कुंजियों का इस्तेमाल किया जाता है; निजी कुंजी का इस्तेमाल हस्ताक्षर करने के लिए और सार्वजनिक कुंजी का इस्तेमाल पुष्टि करने के लिए किया जाता है.

पे लोड भेजते समय, पहले उस पर हस्ताक्षर करें और फिर उसे एन्क्रिप्ट (सुरक्षित) करें. जब कोई पेलोड मिलता है, तो सबसे पहले उसे डिक्रिप्ट करें. इसके बाद, हस्ताक्षर की पुष्टि करें.

JWE का इस्तेमाल करते समय, पार्टनर को इन विकल्पों के साथ काम करना होगा:

• कॉम्पैक्ट सीरियलाइज़ेशन.
• एक से ज़्यादा JWE कुंजियों में से किसी एक से पेलोड को डिक्रिप्ट करना.
• कुंजी मैनेजमेंट के लिए, RSA-OAEP, RSA-OAEP-256 या ECDH-ES एल्गोरिदम.
  • यह वैल्यू, alg हेडर (rfc7518 section 4.1) में अपने-आप भर जाती है.
• कॉन्टेंट को एन्क्रिप्ट करने के लिए, A256GCM, A128GCM, A128CBC-HS256 या A256CBC-HS512 एल्गोरिदम.
  • enc हेडर में अपने-आप भर जाता है.
• सार्वजनिक सुरक्षा कुंजी की पहचान करने के लिए, kid हेडर.
• JWE एन्क्रिप्शन का इस्तेमाल करने वाले मैसेज पेलोड के लिए, कॉन्टेंट टाइप application/jose; charset=utf-8 का इस्तेमाल करना ज़रूरी है.

JWS का इस्तेमाल करते समय, पार्टनर को इन विकल्पों के साथ काम करना होगा:

• कॉम्पैक्ट सीरियलाइज़ेशन.
• एक से ज़्यादा JWS कुंजियों में से किसी एक से पेलोड की पुष्टि करना.
• हस्ताक्षर बनाने के लिए, HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, PS384 या PS512 एल्गोरिदम.
  • यह वैल्यू, alg हेडर (rfc 7518 सेक्शन 3.1) में अपने-आप भर जाती है.
• निजी साइनिंग पासकोड की पहचान करने के लिए kid हेडर.

JWE/JWS स्ट्रिंग को UTF-8 स्ट्रिंग के तौर पर एन्कोड किया जाएगा. साथ ही, उनके पेलोड में कोई भी बाइट हो सकती है.

निजी पासकोड, RSA/ECDH-ES पासकोड होने चाहिए. इनकी समयसीमा एक साल होनी चाहिए और इनकी ज़्यादा से ज़्यादा समयसीमा दो साल होनी चाहिए. सभी निजी कुंजी की पहचान हमेशा पार्टनर के सर्वर पर होनी चाहिए. साथ ही, सभी हस्ताक्षर वैल्यू की गिनती पार्टनर के सर्वर पर की जानी चाहिए.

डेवलपमेंट शुरू करने से पहले, आपको Google के साथ JWE और JWS कुंजियां शेयर करनी होंगी. कुंजियों को JWK फ़ॉर्मैट में बदला जाना चाहिए. इसके बारे में rfc7517 में बताया गया है. इस चरण में, आपको सार्वजनिक-निजी कुंजी की जोड़ी जनरेट करनी होती है. साथ ही, Google को सार्वजनिक कुंजी देनी होती है और Google से सार्वजनिक कुंजी वापस लेनी होती है. डेवलपमेंट के दौरान, आपको सिर्फ़ सैंडबॉक्स कुंजियां एक्सचेंज करनी होंगी. इनका इस्तेमाल डेवलपमेंट और टेस्टिंग के लिए किया जाता है. ये कुंजियां, प्रोडक्शन के बाहर इस्तेमाल की जाती हैं. प्रोडक्शन टेस्टिंग और लॉन्च से पहले, आपको प्रोडक्शन की कुंजियों को फिर से बदलना होगा.