2012-04-02 8 views
10

Quiero eliminar datos confidenciales de la memoria en mi aplicación iOS. En Windows solía usar SecureZeroMemory. Ahora, en IOS, utilizo memset viejo y simple, pero estoy un poco preocupado el compilador podría optimizarlo: https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/coding/771-BSI.html¿Cuál es la forma correcta de borrar datos confidenciales de la memoria en iOS?

fragmento de código:

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

Respuesta

3

Parafraseando 771-BSI (enlace ver OP):

Una manera de evitar tener la llamada memset optimizado por el compilador es acceder a la memoria intermedia de nuevo después de la llamada memset de manera que obligaría a que el compilador no para optimizar la ubicación Esto se puede lograr mediante

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

después de la llamada memset().

De hecho, se podría escribir una función secure_memset()

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

(Código tomado de 771-BSI. Gracias a Daniel Trebbien por señalar un posible defecto de la propuesta de código anterior.)

¿Por qué volatile previene la optimización? Ver https://stackoverflow.com/a/3604588/220060

ACTUALIZACIÓN Lea también Sensitive Data In Memory porque si usted tiene un adversario en su sistema iOS, tu ya son más o menos atornillado, incluso antes de que él intenta leer esa memoria. En un resumen, SecureZeroMemory() o secure_memset() realmente no ayudan.

+0

Pensé que tal vez haya un equivalente a SecureZeroMemory() en iOS. Su solución se ve bien, pero ¿qué pasa con "La solución debe ser efectiva en la mayoría de las plataformas, pero consulte la documentación de la plataforma para verificar que es suficiente hacer referencia a un personaje de esta manera". – HyBRiD

+0

Creo que esto es solo patinar de un lado a otro. Lo dicta el estándar que los accesos a las variables volátiles NO deben optimizarse. De hecho, podría ser que un personaje sea un puerto de hardware y un acceso de lectura active algo en el nivel de hardware. Con la volatilidad declaras al compilador que lo sabes mejor que él y que ni siquiera piensa en tratar de optimizar ese acceso. Y como ese acceso depende de memset() al frente, el memset() no se optimizará. – nalply

+0

Su función 'secure_memset' puede no ser suficiente. Según http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf, existen compiladores de optimización que solo pondrán a cero el primer byte. –

0

El problema es NSData es inmutable y no lo hace tener control sobre lo que sucede. Si usted controla el búfer, puede usar dataWithBytesNoCopy: length: y NSData actuará como un contenedor. Cuando termine, podría configurar su búfer.

Cuestiones relacionadas