Creación de una aplicación SMS cifrada (Android) [cerrado]

Question

Creación de una aplicación SMS cifrada (Android) [cerrado]

#1 de Ángel (2 votos)

1

Desde mi búsqueda en Google limitada, me he dado cuenta de que muchas de las aplicaciones de mensajería cifradas más comunes son todas (o una combinación de) de código cerrado, se ejecutan a través de un servidor de terceros no controlado, utilizan un algoritmo propietario o usan algoritmos obsoletos. En mi opinión, esto es simplemente inaceptable.

Mi plan era crear una aplicación de esqueleto de código abierto que implemente una interfaz de usuario de mensajería básica, luego construir un sistema que maneje algoritmos de cifrado personalizados mediante complementos de código abierto.

Espero que al usar un sistema de complementos, los usuarios puedan elegir libremente qué algoritmo usar y que los propios complementos se enfrenten a un serio escrutinio por parte de la comunidad de seguridad general.

Por qué publico esto aquí: actualmente sé muy poco acerca de cómo manejar adecuadamente los datos cifrados. ¿Cuáles son los puntos débiles en esta implementación? ¿Cómo se imponen los complementos de código abierto?

Notas generales:

Sé que los SMS de un proveedor de servicios cuentan como un servicio de terceros. Estoy pensando en incluir la funcionalidad para dirigir la aplicación a un servidor de su elección, de modo que tenga más control sobre sus canales de comunicación (aunque creo que su ISP todavía puede rastrear metadatos y lo que sea que tenga)
Inicialmente, mi plan es solo admitir intercambios de claves en persona (o cualquier método de autenticación requerido). Con el tiempo, si la aplicación resulta útil y se usa, la implementación del servidor personalizado mencionada anteriormente podría usarse para autenticaciones remotas

encryption android instant-messaging plugins opensource

pregunta Todd Schwine 18.05.2016 - 22:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption android instant-messaging plugins opensource

certificado implícito ECDSA usando OpenSSL XSS desde la carga de imágenes: ¿el recorte resuelve la mayoría de los problemas?

score 2 · Answer 1

Estás reinventando la rueda. No creo que el estado del arte realmente justifique crear una nueva aplicación desde cero (OTOH, si quieres hacerlo por otras razones, como practicar la creación de una aplicación, hazlo).

Tenga en cuenta que con el cifrado seguro, el servidor de terceros no podría interceptar las conversaciones (aunque podría registrar metadatos). Y si es de código abierto, podría reemplazar el servidor con bastante facilidad por el suyo.

Sería interesante que detallara las aplicaciones que evaluó junto con las razones que tuvo para descartarlas, ya que sospecho que el panorama no es tan malo .

Espero que al usar un sistema de complementos, los usuarios puedan elegir libremente qué algoritmo usar y que los propios complementos se enfrenten a un serio escrutinio por parte de la comunidad de seguridad general.

Necesitas una línea de base. Puede terminar fácilmente con usuarios divididos por su elección de complementos incompatibles. También se acepta generalmente que la mayoría de los legos toman malas decisiones de seguridad.

Lo que propones es correcto como diseño, pero simplemente puedes ofrecer un único algoritmo seguro, luego actualizar la aplicación con uno más fuerte cuando sea necesario.

Si el usuario puede dirigir las aplicaciones a un servidor de su elección, ¿cómo se comunicarán? ¿Todos necesitan configurar el mismo servidor? ¿Qué pasa si tengo varios contactos en contactos separados? ¿Vas a diseñar un servicio federado?

Trabajar sobre SMS tiene algunas propiedades agradables, pero también significa que debe ajustar todo en el sms, realizar un seguimiento de los contactos que tienen el programa instalado y, por lo tanto, la comunicación debe estar encriptada. Y que no lo hayan desinstalado ni cambiado el terminal. Esto fue un problema para TextSecure ( que terminó eliminando sms encriptados ) o incluso Blackberry cuando las personas cambian de terminal.

la implementación del servidor personalizado mencionada anteriormente podría usarse para autenticaciones remotas

No veo una mención de la implementación del servidor personalizado para la autenticación remota en su pregunta, pero debo tener en cuenta que la autenticación remota es, en mi opinión, la parte más débil en la mayoría de estas aplicaciones de mensajería (a diferencia de su propio cifrado, cuando sí lo tienen) encriptación de extremo a extremo, ya que el servidor puede responder fácilmente por alguien completamente diferente.

Usar identificadores que no sean números de teléfono (como una huella digital clave) sería un poco más molesto, pero es preferible en términos de seguridad y privacidad.