Sì, ma non farlo.
Se stai chiedendo se è possibile elaborare uno schema proprietario per la crittografia dei dati che solo la tua applicazione "sa", la risposta è sì, fino a quando qualcuno non capirà come decodificarlo (che di solito è più facile di tu realizzi). Questo tipo di pratica è noto come sicurezza per oscurità ed è altamente scoraggiato .
Invece, la tua applicazione dovrebbe utilizzare uno schema di crittografia di pubblico dominio (e quindi provato e ben testato). Per fornire specificità dell'applicazione, utilizza una chiave crittografica che solo l'applicazione "sa" ". Un hacker che tenta di decodificare la chiave potrebbe avere un certo successo, ma i parametri che governano quel successo (ad esempio quanto tempo ci vorrà e la potenza di calcolo richiesta) sono ben noti e compresi e si può escogitare una strategia di rischio globale adeguata al livello di sicurezza richiesta dal tuo business case (ad es. puoi usare chiavi più lunghe o cambiarle più spesso).
La crittografia è solo una parte del problema
Non sei sicuro di quali siano i vettori di attacco che stai tentando di mitigare, ma suppongo che tu voglia un'applicazione "visualizzatore di immagini" che sia l'unico modo per visualizzare un'immagine, e inoltre stai lavorando partendo dal presupposto che l'applicazione possa cadere nelle mani di un hacker. Se questi sono corretti, ti trovi di fronte a un problema molto difficile (endpoint client compromesso).
Di solito, se c'è un endpoint client compromesso, noi professionisti della sicurezza rinunciamo. Una soluzione completamente a prova di proiettile è quasi impossibile. Ma sono stati fatti tentativi, e questi rientrano nel lessico di Digital Rights Management (DRM) . Ecco alcuni dei problemi che dovrai risolvere:
- Hai bisogno di un percorso multimediale protetto .
Anche se tutta la sicurezza della tua app funziona, è comunque necessario visualizzare l'immagine e il modo in cui il tuo O / S visualizza un'immagine sta utilizzando un driver video. Bene, chiunque può scrivere il proprio driver video e non c'è nulla che impedisca a un driver video di registrare e archiviare un'immagine per uso involontario. Il modo tipico per far fronte a questo è richiedere che le librerie dei driver video siano firmate digitalmente e che l'O / S verifichi la firma prima di consentire all'output di andare al driver.
- Devi proteggere la memoria dell'applicazione
Indipendentemente da quanto sia intelligente la tua app, un hacker può trovare un modo per accedere alla sua memoria se ha accesso fisico alla macchina. Un minimo di attenuazione per questo è quello di eseguire un piccolo codice per verificare se eventuali debugger sono attualmente in esecuzione sul sistema e interrompere l'output se ci sono. È improbabile che questo fermi un hacker determinato che ha modi per mascherare cose del genere.
- Devi proteggere il contenuto e la chiave
Le soluzioni che ho visto riguardano la memorizzazione dei media in formato crittografato (usando una chiave simmetrica - una chiave pubblica / privata è troppo lenta). Quando il visualizzatore viene eseguito, richiede una chiave da un server, utilizzando un documento firmato che indica che ha il diritto di richiedere la chiave. La chiave viene archiviata in memoria e il contenuto viene decodificato, quindi la chiave viene sovrascritta in memoria con dati casuali e scartata.
- Devi impedire all'hacker di scattare una foto del monitor video
Un problema piuttosto difficile da risolvere. Anche se fai tutte queste cose sulla sicurezza, niente al mondo impedirà a qualcuno di tirare fuori la macchina fotografica e di scattare una foto dello schermo. Ovviamente, questo sarebbe molto rischioso, ma con un buon monitor e una buona fotocamera è comunque possibile ottenere un'immagine eccezionale.
L'unica soluzione per questo mi viene in mente di includere una filigrana sensibile al contrasto sull'immagine stessa. Questo potrebbe essere o non essere accettabile per te.