iOS, firma de perfil de MDM, ¿qué certificate usar?

De acuerdo, entonces mira este diagtwig .

Hay dos cuadros pequeños, que indican cómo se debe firmar un perfil determinado.

En la Fase 2, paso 1, dice "certificate emitido por Apple", pero no dice qué certificate emitido por Apple (emiten más de uno). He probado mi certificate de desarrollador y el certificate MDM (APNS). No fue uno de esos. ¿Hay algún tercer certificate mágico que de alguna manera necesito (y cómo lo consigo)?

En la Fase 3, paso 2, dice "Certificado de identidad", pero nuevamente es un poco esquemático en los detalles. El único certificate de identidad que conozco está instalado en el dispositivo, utilizando la key privada del dispositivo, ¿cómo se supone que el server debe usar eso para firmar un perfil?

La única manera de que esto funcione es creando mi propio certificate autofirmado y preinstalado en el dispositivo. Obviamente, esta no es una forma elegante o particularmente segura de hacer las cosas.

Preguntas de seguimiento

Mi certificate de server es emitido por "DigiCert High Assurance EV Root CA" y está en la list: http://support.apple.com/kb/ht5012 , pero los dispositivos iOS 6 consideran "no confiable" cuando firmas perfiles, pero está bien para SSL que es extraño. Los dispositivos con iOS 5 están bien. ¿Alguna idea de por qué?

Realmente no entiendo el bit de encriptación tampoco. De la documentation de MDM: "Cada dispositivo debe tener un certificate de identidad de cliente único. Puede entregar estos certificates como contenedores PKCS # 12, o a través de SCEP. El uso de SCEP se recomienda porque el protocolo garantiza que la key privada para la identidad exista solo en el dispositivo."

Aunque estoy de acuerdo en que es más seguro que solo el dispositivo conoce su key privada, es algo problemático ya que una key pública de 2048 bits solo se puede usar para cifrar cerca de 100 bytes de datos, lo cual no es suficiente incluso para el menor posible carga útil.

Déjame repasar la fase 2 y la fase 3 primero

En la Fase 2, paso 1, el dispositivo iOS enviará a una respuesta del server que está firmada por el certificate / key del dispositivo (cada dispositivo viene con un certificate / key preinstalado que es diferente para cada dispositivo). Estos en los certificates / keys del dispositivo son emitidos por Apple.

En el lado del server, debe verificarlo mediante Apple Root Cetificate.

En la Fase 2, el paso 1-3 su service de perfil enviará una request de SCEP. Esta request de SCEP contiene información para que el dispositivo sepa a qué server de SCEP debe hablar. Este server SCEP es su server. Entonces, un dispositivo hablará con este server SCEP y le solicitará un nuevo certificate de identidad.

En la Fase 3, la respuesta del dispositivo del paso 2 se firmará con el certificate / key de este certificate de identidad. Y ahora debería verificarlo con su certificate raíz de la autoridad de certificación. (Una nota más, el server SCEP en la Fase 2 es una especie de proxy a la suya Autoridad de certificación)

Y ahora respondiendo a sus preguntas "Perfil MDM signining, ¿qué certificate usar?"

El perfil de MDM se puede cifrar y / o firmar.

Si desea cifrarlo, cifrelo utilizando el certificate de identidad asociado con este dispositivo. Entonces, dispositivo que tiene una key para esta identidad, para que pueda descifrarla.

Si desea firmarlo, firma con la key del server. El dispositivo debe tener instalado un certificate de server para que pueda verificar la firma.

Por cierto En esta asignatura. Una cosa que no se muestra en este diagtwig, pero que generalmente se requiere: el primer paso (antes de completar esta inscripción) suele ser la installation del certificate del server (para la futura verificación de la firma del perfil). Potencialmente, puede omitir este paso si su certificate de server es emitido por CA conocida (como ejemplo Verisign o algo por el estilo).

Déjame saber si tienes alguna pregunta de seguimiento. Me tomó un time entender toda esta inscripción OTA / MDM.

Actualización 1

No sé por qué iOS 6 trata su certificate como no confiable para firmar. No trabajé con certificates que fueron firmados por conocidos CA's.

Solo tengo una suposition. Podría ser que entre iOS 5 e iOS 6 cambiaron algo con respecto a la cadena dominante. En términos generales, cada aplicación tiene su propio llavero. Y todos los certificates bien conocidos, creo que deberían savese en el llavero Mobile Safari. Podría ser que MDM / Preferences compartiera este llavero con MobileSafari en iOS 6 y ahora no lo compartan. En tal caso, deberá instalar esta "CA Root Root de DigiCert High Assurance" a través de un perfil (para ponerlo en el llavero correcto). Sin embargo, es una conjetura salvaje.

Sobre encriptación. En primer lugar, tienes razón, si cada dispositivo tiene su propia key privada, es mucho más seguro. En tal caso, si alguien roba un perfil, no podrá descifrarlo (porque solo un dispositivo tiene una key privada para hacerlo). Esto es especialmente crítico, si está enviando perfiles que son sensibles (como ejemplo, count de correo electrónico con nombre de usuario y contraseña).

Introducción de muy alto nivel en cryptography:

Cualquier key (con cualquier longitud) puede cifrar datos de cualquier longitud. Todos los algorithms de encryption están diseñados de esa manera para que pueda usar la misma key para cifrar cualquier cantidad de datos.

Los algorithms asimétricos (como RSA) rara vez se usan para cifrar datos directamente. En la mayoría de los casos, este algorithm se utiliza para cifrar una key para un algorithm simétrico (como el ejemplo AES) y todos los siguientes encryptions / desencryptions se realizan mediante AES. Hay dos razones para eso: el performance (AES es más rápido que RSA) y los resources (AES tiene less resources que RSA).

Entonces, como resultado, si necesita cifrar el perfil, usa PKCS7 , que internamente usa RSA, AES (u otros algorithms). Por lo general, tiene una biblioteca para hacer esto (OpenSSL o BouncyCastle). Entonces, no tienes que descifrar todas estas complejidades.

Por cierto Si tiene preguntas que no son adecuadas para el SO, puede contactarme directamente (mi información de contacto en mi perfil).