Función de cifrado dentro del código PHP que tiene que publicar

Con el motor estándar, no puedes. Hay una serie de ofuscadores de código disponibles, así como varias herramientas de protección de código PHP, pero ninguna le ofrecerá una buena protección contra un atacante que sabe lo que está haciendo.

Hay un problema adicional que leí en su descripción de su problema: parece que desea proteger contraseñas u otros datos secretos mediante la ofuscación de códigos. Si ese es el caso, entonces deténgase allí: NO hay forma de proteger dichos datos de alguien con un depurador si sigue ese camino. Todo lo que puede hacer es reducir la velocidad de un atacante potencial, de modo que su única esperanza es que la información que desea proteger no valga la pena el tiempo invertido en recuperarla.

Si realmente debe proporcionar una seguridad de datos sólida en su aplicación, deberá encontrar otro modelo (que dependerá de lo que esté haciendo, exactamente).

Bueno, usted sabe que cada software en el usuario final (ya sea un cliente, un cliente habitual que está viendo un video, etc.) puede tener ingeniería inversa.

Y eso se aplica a cualquier solución como "descargar las claves de un servidor", porque una vez que se descompila el programa, el usuario tiene acceso a él.

No creo que nadie aquí pueda ofrecerle una mejor solución que las herramientas comerciales que ya le brindamos, así que si solo quiere hacer que sea más difícil para su cliente, vaya con esas ofuscaciones: soluciones de encriptación y esperanza. para lo mejor.

También puedes intentar usar algún hardware personalizado (como un token) que tendrá parte del código, o alguna función esencial, dentro de él. Y también puede tener algún servicio web, de modo que su cliente acceda a su servidor web y solo reciba los datos después de que realice el procesamiento. Y, por supuesto, estas dos alternativas tienen inconvenientes.

Ya que su comentario aclaró que necesita entregar una máquina completa (o VM) y si tiene eso en mente, entonces está en un juego de pelota diferente. Olvídate de tratar de hacer algo con o con PHP, no es seguro que los atacantes tengan acceso a él y tratar de hacerlo de esa manera es posiblemente una tarea de tontos.

La entrega de toda la máquina, sin embargo, tiene mucho más margen para asegurar el acceso. Probablemente pueda obtener ayuda si tiene la posibilidad de volcar los derivados de Linux a favor de un BSD que tenga un modelo de seguridad más sólido, según tengo entendido.

La seguridad es siempre relativa. Si tienen el control de la caja y están determinados, dotados de recursos y lo suficientemente capacitados, podrán superar cualquier cosa que implementes. Otras opciones podrían ser más rentables en el sentido de permitirles pensar que han roto su seguridad y registro cuando se han incumplido los acuerdos de uso para que los cargue en consecuencia.

Para una protección adicional a la que ya proporciona la codificación, desviarse de una compilación PHP estándar ofrecería algunas ventajas, y podría usar un módulo basado en C personalizado donde la clave se compila en el módulo y no existe dentro del código PHP. Sin embargo, considere qué protección hay para los datos antes de que se cifre; PHP en sí mismo es de código abierto y se puede modificar, por lo que existen riesgos inherentes y las soluciones de hardware mencionadas en las respuestas pueden no ayudar, y no son inmunes a la ingeniería inversa.

Steinberg usó dongles de hardware para Cubase, que fueron exitosamente diseñados con ingeniería inversa y se lanzaron emulaciones de software. A pesar de la sofisticada protección contra manipulación indebida en el chip, como los detectores de luz y la monitorización del voltaje de la señal, las tarjetas de visualización del decodificador de hardware utilizadas para un servicio de televisión del Reino Unido llamado en digital fueron diseñadas con ingeniería inversa, supuestamente por un competidor, lo que dio lugar a tarjetas clonadas siendo producido y la desaparición resultante de la empresa. El objetivo de la protección es hacer que la ingeniería inversa sea lo más complicada, costosa y lenta posible, pero nunca se puede evitar.

Cuando entregas un sistema operativo en las manos de tu atacante, no puedes evitar que lo realicen ingeniería inversa. No hay excepciones.

Pero con una distribución inteligente de claves y certificados, puede aliviar algunos de los problemas. Si cada usuario obtiene su propia clave y certificado (firmado por usted), entonces puede identificar de manera única a ese usuario por cualquier cosa que firme. Compartir su clave revelaría la identidad de la persona que la compartió.

Del mismo modo, al distribuir claves públicas para cifrar los datos salientes, puede limitar el descifrado solo a aquellas máquinas que poseen la clave privada asociada.

EN RESPUESTA AL COMENTARIO

  

solo necesito los datos estrictamente confidenciales de alguna manera almacenados en el disco duro cifrado y el descifrado solo debería ser posible a través de mi software.

Has perdido en "el descifrado solo debería ser posible a través de mi software" . Esto es absolutamente imposible al 100%. Lo que has descrito es, exactamente, DRM. Lea la la explicación de Cory Doctrow sobre esto hace casi una década. Algunas de las personas más inteligentes y con mayor motivación financiera han trabajado en esto, y continúan trabajando en esto hasta el día de hoy, y en ningún momento han funcionado. Porque no puede.

En su lugar, lo que puede hacer es hacer el descifrado solo en su servidor , o una solución similar. La forma (la ÚNICA) de evitar que el cliente descifre sus datos es no darle la clave . Lo que significa que él no puede ser el que lo descifra.