Architettura software sicura

Question

Architettura software sicura

#1 da (1 voti)

1

Sto progettando un'architettura software e ho bisogno di suggerimenti e chiarimenti su alcuni problemi.

Questa sarà un'API RESTfull lato server per l'accesso ai dati e più client mobili / desktop per accedere all'API, raccogliere alcuni dati e beni digitali da consumare nei client. Sarà accessibile tramite HTTPS

I client saranno iOS (Swift 2), Android (Java), Windows Phone (C #), Windows (C #), Windows Store (C #), Mac (Swift 2), Web (C # / JavaScript / HTML), Linux (Il linguaggio di programmazione non è ancora chiaro)

Il linguaggio di programmazione delle applicazioni lato server sarà C # su .Net Framework 4.6 e verrà eseguito su Azure

I client possono essere eseguiti su un computer (MAC, PC, Linux), browser, smartphone o tablet (iOS, Android, Windows Phone, Windows Store)

I client effettueranno l'autenticazione al servizio REST utilizzando oAuth 2, quindi il membro effettuerà l'autenticazione utilizzando il nome utente e la password. L'ID univoco del membro verrà archiviato nel database del cliente per l'autenticazione e la richiesta all'API per gli ulteriori passaggi / richieste poiché non sarà richiesto alcun accesso se il membro si disconnette intenzionalmente.

Quando la richiesta del membro da API ci sarà un processo di download per file digitali di medie dimensioni (come pdf o file video di circa 200 mb). I file verranno crittografati sul server per decodificare sul client mentre sta consumando. Ciò significa che decodificheremo i prodotti digitali in fase di runtime, quindi nessun file verrà archiviato nel client decrittografato. Quindi la mia decrittografia deve essere molto veloce e con un basso consumo di risorse, ma sicuro.

I membri saranno autorizzati a registrare -let dicono 3 dispositivi per utilizzare il software client

I dispositivi client verranno registrati automaticamente quando il membro utilizza per la prima volta l'app sul dispositivo.

I file devono essere consumati nel client se il cliente è registrato, il membro è valido e il prodotto digitale viene acquistato dal membro. Nessun altro utente o qualsiasi altro software non sarà in grado di consumare prodotti.

Ecco il mio approccio iniziale per implementare i requisiti di cui sopra nel software in modo da poter proteggere i prodotti e il sistema:

I could not managed to enter all my explanations in here because form was saying this is a spam. that is why i have add a link below so you can find all my notes in there

https://cryptbin.com/EDu#716f72dbd22ede12531a83cba4e464fb

Ecco le mie domande;

Terrò la password dei miei membri nel database con l'hash SHA-512. Userò SALT per la password. Quindi terrò le chiavi SALT nel database per ogni membro. È sicuro e va bene implementarlo in questo modo?
Devo tenere IV (Initialization Vector) nel database per ciascun prodotto in modo da poterlo utilizzare per la crittografia? Se è così ho bisogno di esporlo tramite la mia API in modo che il client possa ottenerlo per decrittografarlo. È sicuro esporre?
Quale algoritmo di crittografia e hash è meglio usare in ambienti diversi senza problemi. Decreterò i file in iOS, Android, Windows Phone, Windows, Mac, ecc. Tutto nativo lo so da un amico che ha usato AES-128 e MD5 sul server per crittografare, ma ha affrontato molti problemi su diversi client quando ha provato a decodificare file.
Sto pensando di utilizzare AES-256 (modalità di cifratura: CBC, modalità di riempimento: PKCS7, con IV) e SHA-512. Qualche commento su questa scelta?
Memorizzerò 2 diverse password di convalida e 2 password di crittografia diverse nel database, così posso usarla con AES e SHA-512. Ma ho bisogno di memorizzare le stesse password nel codice client come testo hardcoded in modo da poter decodificare il prodotto. Ma questa password può essere rubata per de-offuscarla. Qual è il modo migliore per mantenere questa password 4 nell'ambiente client e altre informazioni importanti sul client?
Quando pubblico iOS, Android e Windows Phone, Windows Store, app Mac sui mercati, vengono automaticamente offuscati e firmati. Firmerò manualmente e offuscerò la mia Applicazione Windows. È sufficiente proteggere il mio codice contro persone curiose?
Sto utilizzando alcuni dati per crittografare o file hash o informazioni. Devo esporre i dati tramite API in modo che i miei clienti possano ottenerli e usarli per la decrittografia. È sicuro farlo? C'è un altro modo per farlo?
Qualche suggerimento sull'architettura che spiego sopra? Prevedi qualsiasi tipo di vulnerabilità sull'approccio?

PS: posso dare maggiori dettagli se abbiamo bisogno di chiarire qualsiasi cosa.

encryption aes sha decryption

posta Walt S. 24.07.2015 - 03:37

fonte

1 risposta

Leggi altre domande sui tag encryption aes sha decryption

kernel: intrusione che mi disconnette Iniezione SQL da file di importazione dati

score 1 · Answer 1

I will keep my members password in database with SHA-512 hash. I will use SALT for password. So i will keep SALT keys in database for each member. Is it safe and ok to implement that way?

Sì, se stai usando il sale (che dovresti), dovresti conservare il sale (in chiaro) accanto all'hash.

Should i keep IV (Initialization Vector) in the database for each product so i can use it for encryption? If so i need to expose it via my API so client can obtain it to decrypt. Is it safe to expose?

Dipende da quale schema / modalità di crittografia stai usando, ma dato che hai citato AES-CBC, non è necessario mantenere il segreto di IV. L'unico requisito è che l'IV sia casuale / imprevedibile.

Which encryption and Hashing algorithm is best to use in different environment without any problem. I will decrypt files in iOS, Android, Windows Phone, Windows, Mac etc. All native I know it from a friend that he used AES-128 and MD5 on server to encrypt but he face lots of problem on different clients when tried to decrypt files.

Gli algoritmi di crittografia e hashing sono indipendenti dalla lingua e dal sistema operativo, dovresti essere in grado di trovare implementazioni nella maggior parte delle lingue. AES e la famiglia SHA sono particolarmente ben supportate e ampiamente utilizzate. Non sono sicuro dei problemi che incontra il tuo amico (e generalmente vorrai evitare MD5).

I am planning to use AES-256 (Cipher Mode: CBC, Padding Mode: PKCS7, with IV) and SHA-512. Any comment on this choices?

I am using some data to encrypt or hash files or information. I have to expose that data over API so my clients can obtain it and use them for decryption. Is it safe to do it? Is there any other way to do it?

Ho intenzione di combinare questi due punti. Presumo che quando dici AES-256 e SHA-512 intendi AES come crittografia e SHA come controllo dell'integrità del messaggio. C'è un problema con questo: dire che crittografare il messaggio e quindi calcolare l'hash per l'integrità. Dato che stai usando la modalità CBC, un avversario può (ad esempio) fare un attacco di bit flipping e quindi ricalcolo l'hash del testo cifrato modificato e non saresti il più saggio. In generale si vorrebbe usare un hash con chiave (come HMAC) per l'integrità e l'autenticità.

Ora (e al secondo punto), c'è qualcosa chiamato Crittografia autenticata con dati aggiuntivi (AEAD) che si occuperà effettivamente dei problemi affrontati nel paragrafo precedente (fornirà riservatezza, integrità e autenticità senza dover costruire uno schema da primitivi). Permetterà inoltre che alcuni dati (i dati aggiuntivi) siano mantenuti in chiaro, ma garantiranno comunque l'integrità di tali dati. Esamina la modalità GCM (ad es. AES-GCM).

I will store 2 different Validation Password and 2 different Encryption password in database so i can use it with AES and SHA-512. But i need to store same passwords in the client code as hardcoded text so i can decrypt product. But this password can be stolen by de-obfuscating it. What is the best way keep this 4 password in the client environment as well as other important client information?

Non sono un esperto in questo senso, ma consiglio vivamente di non codificare una password nel client. Qualsiasi hacker ragionevolmente intelligente sarà in grado di recuperare questa password in un tempo minimo, quindi non c'è davvero alcuna sicurezza qui.

When i publish iOS, Android and Windows Phone, Windows Store, Mac apps to the markets then they are getting obfuscated and signed automatically. I will manually sign and obfuscate my Windows Application. Is it enough to protect my code against curious people?

La mia comprensione è che il codice di firma / un'app è quello di dimostrare l'autenticità del codice all'utente finale, in modo da garantire che un avversario non abbia backdoor il codice / l'app che ha scaricato o qualcosa del genere, e non rendere più difficile la decompilazione / il reverse engineering. L'offuscamento potrebbe anche non essere sufficiente per tenere un avversario dedicato nel capire come funziona la tua fonte o nel recuperare i dati sensibili nel tuo codice. Mi è sempre sembrato un caso di sicurezza attraverso l'oscurità .