Pregunta

Actualización: esta pregunta trata específicamente de proteger (cifrar / ofuscar) el contenido del lado del cliente en lugar de hacerlo antes de la transmisión desde el servidor. ¿Cuáles son las ventajas y desventajas de adoptar un enfoque como el de itune, en el que los archivos no se cifran / ofuscan antes de la transmisión?

Como agregué en mi nota en la pregunta original, hay contratos vigentes que debemos cumplir (como es el caso para la mayoría de los servicios que implementan drm). Presionamos por drm free, y la mayoría de las ofertas de proveedores de contenido están en él, pero eso no nos libera de las obligaciones ya existentes.


Recientemente leí alguna información sobre cómo itunes / fairplay se acerca a drm, y no esperaba ver que el servidor realmente sirve los archivos sin ninguna protección.

La cita en esta respuesta parece capturar el espíritu del problema.

  

El objetivo debería ser simplemente "mantener   gente honesta honesta " ;. Si vamos   más allá de esto, solo dos cosas   suceder:

     
      
  1. Peleamos una batalla que no podemos ganar. Aquellos que quieran hacer trampa tendrán éxito.
  2.   
  3. Hacemos daño a los usuarios honestos de nuestro producto al hacer que sea más difícil de usar.
  4.   

No veo ningún impacto en los usuarios honestos aquí, los archivos estarían vinculados al usuario, independientemente de si esto sucede del lado del cliente o del servidor. Esto le da otra oportunidad a aquellos en 1.

Un poco de información adicional: el entorno del cliente es adobe air, involucrando múltiples tipos de contenido (música, video, aplicaciones flash, imágenes).

Entonces, ¿es razonable hacer como el juego limpio de itune y proteger el lado del cliente de medios?

Nota: creo que el DRM irrompible es un problema insoluble y, como la mayoría busca una respuesta a esto, la necesidad de esto se relaciona con que ya está en un contrato con proveedores de contenido ... en el mejor esfuerzo razonable.

¿Fue útil?

Solución

Para responder la pregunta "¿es razonable", debe ser claro cuando usa la palabra "proteger" de qué estás tratando de protegerte ...

Por ejemplo, ¿estás intentando:

    ¿
  1. usuarios autorizados de usar su contenido descargado a través de su aplicación bajo ciertas circunstancias (por ejemplo, vencimiento del período de alquiler, copiado a una computadora diferente, etc.)?
  2. ¿
  3. usuarios autorizados de usar su contenido descargado a través de cualquier aplicación bajo ciertas circunstancias (por ejemplo, vencimiento del período de alquiler, copiado a una computadora diferente, etc.)?
  4. usuarios no autorizados pueden usar contenido recibido de usuarios autorizados a través de su aplicación ?
  5. usuarios no autorizados pueden utilizar el contenido recibido de usuarios autorizados a través de cualquier aplicación ?
  6. los usuarios conocidos acceden a contenido no comprado / no autorizado desde la biblioteca de medios en su servidor a través de su aplicación ?
  7. los usuarios conocidos acceden a contenido no comprado / no autorizado desde la biblioteca de medios en su servidor a través de cualquier aplicación
  8. usuarios desconocidos acceden a la biblioteca de medios en su servidor a través de su aplicación ?
  9. usuarios desconocidos acceden a la biblioteca de medios en su servidor a través de cualquier aplicación ?

etc ...

" Cualquier aplicación " en lo anterior puede incluir cosas como:

  • otros programas de reproductor diseñados para interoperar / cooperar con su sitio (por ejemplo, para flickr )
  • programas diseñados para convertir contenido a otros formatos, posiblemente formatos no DRM
  • programas hostiles diseñados para

Desde el artículo que vinculó, puede comenzar a ver algunas de las posibles limitaciones de aplicar el lado del cliente DRM ...

  
      
  • El tercero, utilizado originalmente en PyMusique, un cliente de Linux para iTunes Store, pretende ser iTunes . Solicitó canciones de los servidores de Apple y luego descargó las canciones compradas sin bloquearlas , como lo haría iTunes.

  •   
  • El cuarto, usado en FairKeys, también finge ser iTunes ; solicita las claves de un usuario de los servidores de Apple y luego las utiliza para desbloquear las canciones compradas existentes .

  •   

Ninguno de estos enfoques requería romper el DRM que se estaba aplicando, o incluso piratear cualquiera de los productos involucrados; podrían hacerse simplemente observando pasivamente los protocolos involucrados y luego imitándolos.

Entonces la pregunta es: ¿estás tratando de protegerte contra este tipo de ataque?

  • En caso afirmativo, el DRM aplicado por el cliente no es razonable .
  • Si no (por ejemplo, solo le preocupan las personas que usan su aplicación, como lo hace Apple / iTunes), entonces podría serlo.

(repita este proceso para cada situación que se le ocurra. Si la respuesta es siempre "DRM aplicado por el cliente me protegerá" o "No estoy tratando de proteger contra esta situación", luego usar DRM aplicado por el cliente es razonable .)


Tenga en cuenta que para los últimos cuatro de mis ejemplos, aunque DRM protegería contra esas situaciones como un efecto secundario, no es el mejor lugar para hacer cumplir esas restricciones. Ese tipo de restricciones se aplican mejor en el servidor en el proceso de inicio de sesión / autorización.

Otros consejos

Creo que te puedes perder algo aquí. Los usuarios odian, odian , odian , HATE DRM. Es por eso que ninguna compañía de medios consigue alguna tracción cuando intentan usarlo.

Lo importante aquí es que el contrato dice "el mejor esfuerzo razonable", y no tengo la menor idea de lo que eso significará en un tribunal de justicia.

Lo que quiere hacer es hacer feliz a su cliente con el DRM que le puso. No sé qué piensa su cliente que DRM es, puede hacer, costos en recursos, o si su cliente sabe que DRM puede ser realmente molesto. Tendrías que responder eso. Puede intentar educar al cliente, pero eso podría verse como un intento de explicar el trabajo deficiente.

Si el cliente no está satisfecho, la próxima posición alternativa es que le paguen sin litigio, y para que eso suceda, el contrato debe ser razonablemente claro. Desafortunadamente, "el mejor esfuerzo razonable" no está claro, por lo que podría terminar en la corte. Puede renegociar partes del contrato a favor del cliente, o puede que no lo haga.

Si todo lo demás falla, espera ganar el caso judicial.

No soy abogado, y este no es un consejo legal. Veo esto como más una cuestión de expectativas y una posible interpretación legal que una cuestión técnica. No creo que podamos ayudarte aquí. Debe consultar con un abogado que se especialice en este tipo de cosas, y ni siquiera sé qué especialidad recomendar. Si se encuentra en los EE. UU., Llame a su Colegio de Abogados local y solicite una referencia.

  

No veo ningún impacto en los usuarios honestos aquí, los archivos estarían vinculados al usuario, independientemente de si esto sucede del lado del cliente o del servidor. Esto le da otra oportunidad a aquellos en 1.

Los archivos vinculados al usuario requieren algún método para verificar que hay un usuario. ¿Qué sucede cuando su servidor de verificación deja de funcionar (o se suspende, como hizo Wal-Mart)?

No existe un nivel de DRM que no afecte al menos a algunos "usuarios honestos".

Los datos se pueden copiar Mientras el hardware del cliente, independiente, no pueda distinguir entre un "bien" y un "malo" copia, terminará limitando todas las copias generales, y copie mecanismos . La mayoría de las empresas de DRM se ocupan de este hecho diciéndome cuánto esta tecnología me libera. Casi como si la gente comenzara a creer cuando escuchan lo mismo con la frecuencia suficiente ...

El código no se puede proteger en el cliente. La protección del código en el servidor es un problema ampliamente resuelto. La protección del código en el cliente no lo es. Todos los enfoques actuales vienen con restricciones mezquinas.

Impact funciona de manera sutil. Como mínimo, tiene el costo adicional de implementar DRM del lado del cliente (y todos los costos de seguimiento, incluida la horda de " DMCA " - gritando abogados gorilas) Es difícil demostrar que compensará este costo con el aumento de los ingresos.


No se trata solo de código y criptografía. Una vez que implementa DRM del lado del cliente, desata una cadena de eventos en Marketing, Relaciones Públicas y Legal. Mientras no se detengan para alienar a los usuarios, no necesita molestarse.

Si el servidor sirve el contenido sin protección, es porque el cifrado es por cliente.

Dicho esto, wireshark frustrará tus mejores planes.

El cifrado solo suele ser tan bueno como enviar un booleano que le dice si puede usar el contenido, ya que la omisión generalmente solo cambia la entrada / salida a una llamada de API de cifrado ...

Desea utilizar la ofuscación binaria pesada en el lado del cliente si desea que la protección se mantenga literalmente durante más de 5 minutos. Usando el descifrado en el lado del cliente, asegúrese de que los datos no puedan reproducirse y que la única forma de evitar el sistema es realizar ingeniería inversa en todo el esquema de protección binaria. Bien hecho, esto detendrá a todos los niños.

En otra nota, si este es un producto que se ejecutará en un sistema operativo, no use anomalías específicas del procesador o del sistema operativo, como Windows PEB / TEB / syscalls y errores del procesador, esos solo harán que el programa incluso menos portátil de lo que ya es DRM.

Ah, y para responder el título de la pregunta: No. Es una pérdida de tiempo y dinero, y hará que su producto no funcione en mi sistema Linux reforzado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top