2010-03-23 19 views
5

मेरी चिंता यह है कि कचरा कलेक्टर द्वारा प्रबंधित क्रिप्टोग्राफिक कुंजी और रहस्य कॉपी किए जा सकते हैं और शून्यकरण के बिना स्मृति में चारों ओर स्थानांतरित हो सकते हैं।मैं कैसे सुनिश्चित कर सकता हूं कि जावा ऑब्जेक्ट (क्रिप्टोग्राफिक सामग्री युक्त) शून्यकृत है?

public class Key { 
    private char[] key; 
    // ... 
    protected void finalize() throws Throwable { 
    try { 
     for(int k = 0; k < key.length; k++) { 
     key[k] = '\0'; 
     } 
    } catch (Exception e) { 
     //... 
    } finally { 
     super.finalize(); 
    } 
    } 
    // ... 
} 

संपादित करें:

एक संभव समाधान के रूप में, यह करने के लिए पर्याप्त है कृपया ध्यान दें कि मेरी समस्या वस्तु की आधिकारिक (संदर्भित) प्रतिलिपि का न केवल zeroization के बारे में है, लेकिन यह भी किसी भी बासी प्रतियां कचरा कलेक्टर हो सकता है जबकि यह अंतरिक्ष और गति दक्षता के लिए स्मृति चारों ओर shuffles।

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

इसके लिए एक लिटमस परीक्षण होगा यदि आप क्रिप्टो मॉड्यूल में एक कुंजी का उपयोग करते हैं, कुंजी को शून्यकृत करते हैं, फिर पूरे जेवीएम प्रक्रिया स्थान का निरीक्षण करते हैं, तो आपको उस कुंजी को ढूंढना चाहिए।

+0

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

+0

मूल जावा वस्तुओं के साथ आप जो चाहते हैं उसे करने के लिए मूल रूप से कोई रास्ता नहीं है (वर्तमान में)। – james

+0

वास्तव में यह सुनिश्चित नहीं है कि बिंदु क्या है। जानकारी स्मृति _somewhere_ में है।अगर किसी हमलावर के पास स्थानीय मेमोरी तक पहुंच है, तो आप बहुत ज्यादा अटक गए हैं। – james

उत्तर

0

तो मैं @jambjo और @james से निष्कर्ष पर आया हूं, कि वास्तव में कुछ भी नहीं है जो मैं चाबियों को कॉपी करने और अनुपस्थित होने से रोकने के लिए कर सकता हूं।

डेवलपर के रूप में सबसे अच्छी रणनीति, क्रिप्टो लाइब्रेरी को सी (या किसी अन्य गैर-प्रबंधित भाषा) में छोड़ना और वहां अपनी सामग्री को लागू करना होगा।

यदि वे बेहतर समाधान के साथ आ सकते हैं तो मैं किसी और से उत्तर स्वीकार करने के इच्छुक नहीं होगा।

4

Java Cryptography Extension Reference Guide हमेशा पासवर्ड के तारों की बजाय चरित्र सरणी का उपयोग करने की सलाह देता है ताकि उन्हें बाद में शून्य किया जा सके। वे how you could implement it का कोड उदाहरण भी प्रदान करते हैं।

+0

यह एक बहुत अच्छा बिंदु है , लेकिन मुझे यकीन नहीं है कि यह पर्याप्त है। कृपया मुझे प्रश्न के लिए हालिया अपडेट देखें। –

+0

किसी सरणी की सामग्री को ओवरराइट करना नए जावा वीएम के साथ पर्याप्त नहीं है, क्योंकि सरणी को प्रक्रिया मेमोरी स्पेस के भीतर चारों ओर ले जाया जा सकता है, उदा। अगर ढेर defragmented है। – jarnbjo

1

आप सबसे अच्छा शर्त एनआईओ में allocateDirect का उपयोग करना है। एक साधु कार्यान्वयन पर, इसे स्थानांतरित नहीं किया जाना चाहिए। लेकिन यह शायद डिस्क पर पेजिंग के लिए योग्य होगा (आप इसे अनुमानित कर सकते हैं, मुझे लगता है) और हाइबरनेशन।

1

तो क्या है यदि स्मृति में डेटा किसी विशिष्ट समय पर ओवरराइट नहीं किया जाता है? अगर आपको अपनी मशीन की मेमोरी पढ़ने वाले हमलावर के बारे में चिंता करने की ज़रूरत है, तो समस्या है, वह उस समय क्या नहीं ढूंढ सकता था।

वास्तविक हमले परिदृश्य क्या आप चिंतित हैं कि जेवीएम की याद में कहीं भी कुंजियां छोड़ी गईं एक गंभीर समस्या हो सकती है? यदि कोई हमलावर JVM की स्मृति को देख सकता है, तो वह अभी भी उन चाबियों को पकड़ सकता है जबकि आप अभी भी उनका उपयोग कर रहे हैं।

और यदि आप JVM द्वारा छोड़े गए मेमोरी को पकड़ने वाले सिस्टम पर एक नियमित उपयोगकर्ता के रूप में चल रहे हमलावर के बारे में चिंतित हैं: AFAIK सभी आधुनिक ओएस शून्य के साथ नई आवंटित स्मृति को ओवरराइट करते हैं।

+0

सबसे पहले, विचार केवल जोखिम शमन है। आपके पास स्मृति में कुंजी जितनी कम होगी, हमलावर द्वारा इसे कम संभावनाओं को देखना होगा। हालांकि, हाँ आप बिल्कुल सही हैं। मेरी समस्या यह है कि मैं काफी प्रतिस्पर्धा कर रहा हूं। FIPS 140-2 आवश्यकताएं हार्डवेयर आवश्यकताओं से ली गई हैं, जहां _everyone_ को हार्डवेयर तक पहुंच माना जाता है, इसलिए आप हमले विंडो को कम करना चाहते हैं। एक सॉफ्टवेयर मॉड्यूल के लिए, यह ज्यादा समझ में नहीं आता है। –