2012-04-02 4 views
10

Ich möchte vertrauliche Daten aus dem Speicher in meiner iOS App löschen. In Windows verwendete ich früher SecureZeroMemory. Nun, in iOS, verwende ich nur alte Memset, aber ich bin ein wenig der Compiler besorgt könnte es optimieren: https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/coding/771-BSI.htmlWas ist der richtige Weg, um vertrauliche Daten aus dem Speicher in iOS zu löschen?

Code-Schnipsel:

NSData *someSensitiveData; 
memset((void *)someSensitiveData.bytes, 0, someSensitiveData.length); 

Antwort

3

Paraphrasieren 771-BSI (link siehe OP):

Ein Weg, um die Memset Anruf durch den Compiler optimiert heraus zu vermeiden, wird der Puffer wieder nach dem Memset Anruf in einer Weise zuzugreifen, die den Compiler zwingen würde nicht um den Standort zu optimieren. Dies kann durch

*(volatile char*)buffer = *(volatile char*)buffer; 

nach dem memset() Anruf erreicht werden.

In der Tat könnte man eine secure_memset() Funktion

void* secure_memset(void *v, int c, size_t n) { 
    volatile char *p = v; 
    while (n--) *p++ = c; 
    return v; 
} 

(-Code von 771-BSI. Dank Daniel Trebbien genommen für den Hinweis auf einen möglichen Defekt des vorherigen Code Vorschlag.) Schreiben

Warum verhindert volatile Optimierung? Siehe https://stackoverflow.com/a/3604588/220060

UPDATE Bitte lesen Sie auch Sensitive Data In Memory, denn wenn man einen Gegner auf Ihrem iOS-System haben, Ihre bereits mehr oder weniger eingeschraubt, noch bevor er diesen Speicher zu lesen versucht. In einer Zusammenfassung helfen SecureZeroMemory() oder secure_memset() nicht wirklich.

+0

Ich dachte, vielleicht ein Äquivalent zu SecureZeroMemory gibt es() in iOS. Ihre Lösung sieht gut aus, aber was ist mit "Lösung sollte auf den meisten Plattformen effektiv sein, aber konsultieren Sie die Plattform-Dokumentation, um zu verifizieren, dass es ausreicht, ein Zeichen auf diese Weise zu referenzieren." – HyBRiD

+0

Ich denke, das ist nur vorsichtig hin und her watscheln. Es wird vom Standard vorgegeben, dass Zugriffe auf flüchtige Variablen NICHT weg optimiert werden sollen. In der Tat könnte es sein, dass das eine Zeichen ein Hardware-Port ist und ein Lesezugriff etwas auf der Hardware-Ebene auslöst. Mit volatile deklarieren Sie dem Compiler, dass Sie es besser wissen als es und dass es nie daran denkt, diesen Zugriff zu optimieren. Und weil dieser Zugriff von dem memset() davor abhängt, wird das memset() nicht wegoptimiert. – nalply

+0

Ihre 'secure_memset' Funktion ist möglicherweise nicht ausreichend. Laut http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf gibt es optimierte Compiler, die nur das erste Byte auf Null stellen. –

0

Das Problem ist NSData unveränderlich ist und Sie nicht habe Kontrolle darüber, was passiert. Wenn der Puffer von Ihnen gesteuert wird, können Sie DataWithBytesNoCopy verwenden: length: und NSData wird als Wrapper fungieren. Wenn Sie fertig sind, können Sie Ihren Puffer einlagern.