Home Forum PROGRAMMAZIONE EMBEDDED [COMPRO] Pulsantiera e circuito intelligente

Questo argomento contiene 12 risposte, ha 2 partecipanti, ed è stato aggiornato da delfino_curioso delfino_curioso 1 anno, 6 mesi fa.

Stai vedendo 13 articoli - dal 1 a 13 (di 13 totali)
  • Autore
    Articoli
  • #59661

    elisabetta
    Membro

    Ciao a tutti
    avrei la necessita’ di realizzare un prototipo di pulsantiera (come da immagine sottostante)

    http://us.123rf.com/400wm/400/400/nicklaw17/nicklaw170801/nicklaw17080100001/3360090-colorful-red-joystick-e-pulsanti-arcade.jpg

    Quindi vorrei realizzare un “apparecchio” con uno o due pulsanti che comunichi con un PC o via RS232 o (preferibilmente) via USB 2.0
    Il computer dovra’ quindi “capire” quale pulsante viene premuto.

    Fin qui probabilmente nulla di complicato.

    La particolarita’ sta nel fatto che il software realizzato (a cui provvedero’ personalmente) dovra’ avere la certezza che la pressione dei tasti avvenga esattamente dall’apparato che voglio utilizzare.

    Mi spiego con un esempio.
    Supponiamo di avere 5 apparati come quelli nella foto.
    Stessa componentistica e numero di pulsanti.
    Ad ogni click dei pulsanti il software ricevera’ un impulso e quindi “capira'” che e’ stato premuto un pulsante.
    Vorrei pero’ che il software riesca a distinguere quale dei 5 apparati e’ stato collegato ed eventualmente comportarsi in modo differente.
    Quindi l’apparato che voglio realizzare dovra’ riuscire a comunicare oltre a “quale pulsante” anche “quale apparato”.

    Resto in attesa di un vostro progetto/proposta.

    Grazie

    Elisabetta.

    #73346
    delfino_curioso
    delfino_curioso
    Partecipante

    1^ possibilità – apparato intelligente: in ogni singolo apparato viene inserito un sistema di controllo (es. un microcontrollore) in grado di capire quale pulsante DEL PROPRIO APPARATO viene premuto, ed invia ad esempio un codice identificativo tipo “apparato x – pulsante k” via USB al pc. Ogni apparato gestisce quindi la propria logica. Approccio però inefficiente, poiché dovresti avere un cavo USB verso il pc per ogni apparato, e le porte USB sono ovviamente limitate .
    2^ possibilità – apparato “stupido”: ogni singolo apparato viene agganciato ad una centralina di controllo, la quale riesce a capire quale pulsante, FRA TUTTI GLI APPARATI CONNESSI, è stato premuto. Sarebbe poi la centralina, tramite unico punto di comunicazione (USB, rs232, cavo LAN etc.), a dire al PC quale pulsante di quale apparato è stato premuto. In questo caso gli apparati sono meri “interruttori”, privi di logica: è la centralina ad essere intelligente. Soluzione più efficiente, ma va inserito un ulteriore elemento (la centralina, appunto).

    In entrambe le soluzioni, il software che gira sul PC intercetterebbe poi la pressione tramite un controllo a polling oppure mediante interrupt.

    Ci sarebbe un’ulteriore possibilità , ovvero passare per la porta parallela del PC invece che trasmettere un codice seriale (che sia via USB o RS232), ma dovresti comunque prevedere una sorta di centralina e comunque oggi tale porta è in disuso nei nuovi PC.

    #73351

    elisabetta
    Membro

    Grazie per il tuo parere e devo dire che la possibilita’ della centralina intelligente e’ quella che preferisco.

    Chiarisco che al PC verra’ collegato solo uno di questi apparati alla volta.
    Questo vuol dire che se venisse collegato quello “non atteso” il PC (non ricevendo il messaggio “apparato X”) non dovrebbe fare nulla…. o sarebbe poi il software a doversi comportare di conseguenza.

    Spero che in questo modo l’inefficienza di cui parli possa venir meno.

    Avrei pero’ alcune domande:
    – si puo’ fare in modo che il messaggio “apparato X” e “tasto premuto” viaggino in modo indipendente l’un dall’altro?
    Quindi poter controllare che l’apparato collegato sia quello atteso a prescindere che il tasto venga premuto.
    – dove verrebbe scritto questo codice identificativo dell’apparato?
    – come si puo’ rendere sicura questa trasmissione? Credo che sia facile poter “sniffare” questo scambio di dati ed aggirare l’ostacolo.
    Quindi se assegno ad un apparato un codice complesso a piacere H2ehdUdhha838Hh2hoiaU4NbS2NbxxQog873 sara’ sempre possibile intercettarlo o “convincere” il computer che quello connesso e’ l’apparato corretto.
    – come si puo’ rendere “non modificabile” o meglio “non copiabile” la logica di ogni singolo apparato?

    Ti rigrazio.

    Elisabetta

    #73352
    delfino_curioso
    delfino_curioso
    Partecipante

    “Chiarisco che al PC verra’ collegato solo uno di questi apparati alla volta.
    Questo vuol dire che se venisse collegato quello “non atteso” il PC (non ricevendo il messaggio “apparato X”) non dovrebbe fare nulla…. o sarebbe poi il software a doversi comportare di conseguenza”.

    A dire la verità, la centralina l’avevo proposta per poter tenere collegati contemporaneamente tutti gli apparati (intendo fisicamente), riuscendo però a capire da quale apparato arrivasse la pressione del tasto. Se gli apparati vanno collegati al PC uno alla volta, allora potresti renderli “intelligenti ed indipendenti”, ovvero trasferire la logica di controllo all’interno di ognuno di essi, senza bisogno della centralina (oppure rimanere sull’idea della centralina che li tiene tutti contemporaneamente collegati, ma con degli interruttori per ogni apparato, così da attivare l’apparato al momento desiderato….).

    “si puo’ fare in modo che il messaggio “apparato X” e “tasto premuto” viaggino in modo indipendente l’un dall’altro?
    Quindi poter controllare che l’apparato collegato sia quello atteso a prescindere che il tasto venga premuto”

    Certo. Invece di mandare il codice completo alla pressione di un tasto, al collegamento dell’apparato X si può fare in modo di avvisare subito il PC di tale connessione, dopodichè ogni tasto premuto sarà interpretato come un tasto proveniente dall’apparato X.

    “dove verrebbe scritto questo codice identificativo dell’apparato?”

    Nel firmware del microcontrollore dell’apparato

    ” come si puo’ rendere sicura questa trasmissione? Credo che sia facile poter “sniffare” questo scambio di dati ed aggirare l’ostacolo.
    Quindi se assegno ad un apparato un codice complesso a piacere H2ehdUdhha838Hh2hoiaU4NbS2NbxxQog873 sara’ sempre possibile intercettarlo o “convincere” il computer che quello connesso e’ l’apparato corretto”

    Ehm…non ho capito la domanda :-) In realtà non ho chiaro chi o cosa dovrebbere rappresentare la minaccia alla sicurezza nello scambio di dati. La trasmissione avviene in modo diretto tra un PC ed una scheda elettronica (che sia la centralina o la scheda di controllo dell’apparato): intendi dire che l’apparato potrebbe “mentire” al PC dicendo di essere la pulsantiera X quando invece è la Y?

    “come si puo’ rendere “non modificabile” o meglio “non copiabile” la logica di ogni singolo apparato?”

    In genere, nello scrivere firmware per microcontrollori, esistono istruzioni (o meglio, configurazioni) per proteggere il codice da successiva scrittura (esempio classico, il firmware delle centraline delle auto o delle moto). Dipende ovviamente dal chip scelto (PIC, AVR, MSP etc…).

    Ora permettimi una domanda, o meglio, un’osservazione.
    Una scheda di controllo autorealizzata è un “pezzo di ferro” per il quale sei tu stessa a decidere come deve parlare col mondo esterno, quali informazioni deve fornire, quali codici memorizzare etc.
    Non è possibile estorcerle delle informazioni se tu non vuoi che vengano fornite. E’ come dire che tale scheda è un elemento “fidato”, ed il dialogo tra essa ed il PC avviene nella modalità che scegli tu. Per dirla in breve, non si tratta di un altro PC (per cui viene lecito immaginare una serie di meccanismi di sicurezza).
    Sembra tuttavia che tu “tema” in qualche misura la connessione tra gli apparati (o la centralina) ed il PC. Mi sbaglio?

    #73361

    elisabetta
    Membro

    Provo ad addentrarmi un po’ di piu’ nello specifico.

    Il rapporto pc/apparato sara’ sempre 1:1 e quindi l’utilizzo della centralina viene meno.

    L’apparecchio da realizzare sara’ in via prototipale collegato via USB al mio pc ma in futuro potrebbe trovarsi a km di distanza, collegato ad un altro pc.
    Probabilmente in uffici che non conosco, che utilizzano sw che non conosco e che adottano sistemi di controllo che ignoro.
    A quel punto chiunque potrebbe “leggere” la logica scritta nell’apparato: diciamo che e’ solo una questione di termini ovvero possiamo usare il termine LEGGERE se si accede direttamente al microcontrollore o SNIFFARE se tale lettura avviene monitorando il traffico della porta USB del PC.
    In entrambi i casi (ovvero uso illecito dell’apparato) ne potrei avere un danno.

    D’altro canto realizzare un circuito con un pulsante non e’ complicato.
    Il complicato e’ rendere questa cosa diversa da altri mille circuiti con mille pulsanti.
    Il SW sul pc deve avere la (ragionevole) certezza che quello collegato e’ il mio apparato (fosse solo per un problema di garanzia).

    Senza addentrarsi in questioni di sicurezza, oltre allo scambio
    bottone premuto –> PC
    deve essere possibile determinare che il bottone premuto provenga sicuramente del mio pulsante.

    Come fare?

    A proposito del messaggio di riconoscimento dell’apparato, se io battezzo l’apparato 1 con il codice H2ehdUdhha838Hh2hoiaU4NbS2NbxxQog873
    quando il pc ricevera’ il messaggio H2ehdUdhha838Hh2hoiaU4NbS2NbxxQog873
    sapra’ che si tratta dell’apparato 1.
    Ma a questo punto sarebbe facile (con un freeware qualsiasi) intercettare il messaggio H2ehdUdhha838Hh2hoiaU4NbS2NbxxQog873 e replicarlo, saltando di fatto la sicurezza.
    La mia domanda di prima era: e’ possibile realizzare un sistema di sicurezza intelligente (algoritmo) che non invii un messaggio fisso e quindi anche se intercettato non possa essere riutilizzato?

    Ok il proteggere il codice da successiva scrittura, ma come lo si protegge da una successiva lettura?
    Non so ancora, in questa fase, cosa andremo a scrivere nel chip scelto (PIC, AVR, MSP ecc…) ma qualsiasi cosa sara’ mi serve un minimo di garanzia che non possa essere letto/duplicato altrove.
    Cosa ne pensi?

    In buona sostanza, se riesco a realizzare un box esterno su cui vi e’ un pulsante che “parla” con un software che sta su un PC via USB, laddove io debba garantire (come persona o come azienda) tale colloquio, vorrei avere la ragionevole certezza che quello collegato al pc sia il mio apparato e non un altro.

    Quindi il “core” di tutto l’attrezzo non e’ il pulsante ne il circuito stampato ne il chip (che tutti insieme costeranno una manciata di euro) ma la logica che garantisca che quel pulsante e’ il mio.

    #73362
    delfino_curioso
    delfino_curioso
    Partecipante

    Vediamo se ho capito.
    Vuoi fare in modo che, quando colleghi l’apparato ad un PC:

    1. il software del PC riconosca che l’apparato connesso sia proprio quello “made in Elisabetta”;
    2. parimenti, l’apparato riconosca che il software per PC che lo sta interrogando sia proprio quello “made in Elisabetta”;

    e la connessione tra le due entità deve avvenire scambiandosi codici di identificazione che possibilmente siano variabili.
    Il tutto al fine di evitare che sniffando lo scambio dati tra i due o estorcendo fisicamente informazioni dall’hardware coinvolto, nessuno sia in grado di riprodurre, contraffare, clonare etc. l’accoppiata SOFTWARE PER PC – APPARATO originali.
    Se ho compreso bene l’esigenza, credo che andrebbe valutata la “ragionevole certezza” con cui poter stare tranquilli che le parti in gioco siano quelle e quelle soltanto.
    Mi spiego meglio. Nel momento in cui questi due elementi passano dalle tue mani a quelle di altri, le tecniche per “fregarti” sono molteplici, sia HW che SW , e non esiste un’unica soluzione “assoluta” per stare tranquilli. Purtroppo la letteratura riporta vari casi di illeciti (duplicazione di eeprom, microprobing del codice esadecimale del microcontrollore, reverse engineering dell’elettronica del PCB, decapping dell’integrato logico, selective laser zapping etc.), oltre a quelli classici di tipo informatico, come tu stessa hai citato (es. sniffing o monitoring del traffico sulle porte). Ovviamente, come per tutto quanto, nel mondo reale ci vuole un motivo più che valido per spingersi in lavori di questo tipo (molte tecniche HW richiedono attrezzatura molto specifica): di certo, se i “segreti da proteggere” sono importanti e vale la pena svelarli, il modo di farlo si trova (esistono addirittura aziende, ovviamente che operano in una velata illegalità, che si occupano di tali tipi di lavori…). Morale della favola: la sicurezza al 100% non ce l’hai :-)
    Piuttosto, a mio parere, converrebbe cercare di rendere difficile la vita al malintenzionato con tante piccole soluzioni che facciano “massa”.
    Esempio 1: Code protection. In alcuni microcontrollori esiste la possibilità di abilitare dei bit per evitare sia di modificare il firmware sia di leggerlo (ovvero se si prova a leggere la memoria programma del chip mediante “probing”, vengono restituiti tutti 0x00 in luogo delle istruzioni esadecimali del firmware; in caso di lettura forzata della memoria, il programma del chip viene in alcuni casi addirittura cancellato).
    Esempio 2: vincolare il dialogo tra il dispositivo ed il software sul PC al reciproco scambio di un codice. I due elementi in gioco parlano solo se “agganciati” allo stesso codice. Magari si potrebbe addirittura “cablare” tale codice nell’HW dell’apparato (tipo una circuiteria a dip-switch che abilita o meno la comunicazione se il codice ricevuto “matcha” con il suo codice).
    Esempio 3: comunicazione criptata tra apparato e PC. Tra loro, le due entità devono parlare “in codice”, cosicchè se intercettati emergono solo un mucchio di caratteri incomprensibili. Magari per tale soluzione si potrebbe adottare un chip crittografico separato (intendo sull’apparato).
    Esempio 4: evitare di far circolare codici di riconoscimento durante lo scambio di dati tra pc ed apparato. Un pò quello che accade nel protocollo di autenticazione CHAP usato presso gli ISP (gli end point detengono il codice di riconoscimento e si scambiano solo un challenge ed un hash code dello stesso con password). http://it.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol
    Esempio 5: Protezione fisica del chip dell’apparato da manomissione. Una soluzione “paranoica” potrebbe essere attivare un relè e mandare in corto il chip non appena si rileva un tentativo di apertura di un eventuale case che lo racchiude…..

    Si potrebbe andare avanti ancora a lungo, considerando tuttavia che tutti questi meccanismi possono comunque essere elusi.
    Il problema di fondo è che, per potersi reciprocamente riconoscere, le due entità devono comunque conservare il proprio identificativo (che sia un codice SW, che sia un codice “cablato” nell’HW, che sia una procedura di riconoscimento etc). Qualunque sia la forma dell’identificativo, aprendo i dispositivi a studiandoli a fondo, direttamente o in reverse engineering, in teoria è possibile risalirvi.
    Il bello sarebbe se le due entità non dovessero detenere al proprio interno l’identificativo per potersi riconoscere. Un’informazione, dunque, che potrebbe cambiare sempre. Ma a quel punto cos’è che matcherebbe, portando quindi al riconoscimento?
    Mi spiace di aver potuto rispondere solo parzialmente alla tua domanda, in fondo non sono un esperto di sicurezza e spero vivamente di sbagliarmi e che un modo SICURO ci sia.
    Io per ora agirei mettendo questi metodi descritti “a cascata”, se poi mi viene in mente altro ti faccio sapere.

    #73372

    elisabetta
    Membro

    Grande “delfino curioso”!!
    Hai colto nel segno.

    Il mio obiettivo non è rendere inattaccabile il tutto in senso assoluto tutta l’infrastruttura ma solamente scremare quel 60/70% di possibilita’ di “facile duplicazione”.
    Dinanzi al mago, ci leviamo il cappello e si cambia strada.

    Detto questo….
    voglio che il SW capisca che l’apparato sia quello “made in Elisabetta”, non il viceversa.
    Non mi importa allo stato attuale che l’apparato abbia una logica di questo tipo e ciò rende molto più semplice il tutto.

    A questo punto bisogna scegliere una tecnica che dia sicurezza, che sia di relativa facile implementazione nonchè che abbia costi contenuti.
    Cosa mi consigli?

    Esempio 1.
    Ottima la strada del “Code protection”.
    Quali sono le controindicazioni?

    L’esempio 2 non è percorribile per le ragioni su citate.
    Non è in piano di dotare l’apparato di una logica tale che inibisca la trasmissione del messaggio.
    L’apparato rimane passivo per quanto concerne la sicurezza: lui manda sempre sia il messaggio del tasto premuto sia il codice “made in Elisabetta”.
    Sara’ poi compito dell’applicazione trarne le dovute conclusioni.

    Tra le altre cose mi era venuto in mente le legare il codice da scambiare (o parte di esso) al clock… ma non potro’ mai avere la certezza che il clock del PC sia allineato con quello dell’apparato.
    Un po’ come la logica del comando RND, RANDOMIZE del Pascal, RND_LO dell’assembler, Math.random del Java, ecc.

    L’esempio 3 come viene implementato a livello di SW?
    Condividendo il protocollo (MD5?) e routine di criptazione?
    Però se “sniffo” il messaggio criptato e lo mando al SW, lui non capira’ l’errata provenienza poiche’ il messaggio è corretto.
    Credo non sia percorribile.

    Esempio 4. Mi potresti fare un esempio dello schema CHAP?
    Il metodo di far accadere/riaccadere il processo di riconoscimento in qualunque momento e’ esattamente quello che intendevo io quando parlavo di far viaggiare in modo asincrono il messaggio del “bottone premuto” e del “made in Elisabetta”.

    Esempio 5. Lasciamo perdere :-)

    Un saluto

    #73383
    delfino_curioso
    delfino_curioso
    Partecipante

    Bene, allora il cerchio si restringe :-)
    Riguardo la questione del code protection, non vedo particolari controindicazioni: al massimo può risultare scomodo dover modificare o debuggare del codice esadecimale che non puoi vedere, nel caso devi fare tutto a livello di sorgente (in genere C) e poi scaricare di volta in volta ex novo l’eseguibile sul micro.
    Per la parte sul protocollo CHAP, prima di farti esempi “efficaci” mi prendo qualche momento per rifletterci bene, non vorrei darti l’esempio da libro di testo o wikipedia che poco si adattano al tuo caso specifico (oltretutto perché non ho freschi i dettagli del procedimento, ho giusto qualche reminiscenza universitaria…..;-) ).
    Ti tengo comunque aggiornata, il tuo “caso” sta diventando sempre più interessante….

    #73385
    delfino_curioso
    delfino_curioso
    Partecipante

    Ciao,
    mi è venuta in mente questa possibilità, basata su un misto di Code Protection e di funzioni hash (tipo ciò che è usato nel protocollo CHAP).

    Allora, da un lato hai il PC al cui interno è memorizzata una password, ad esempio “pippo&pluto”. Tale password è CRIPTATA mediante una chiave che NON è memorizzata nel PC e conosce solo chi è autorizzato ad usare il tuo software. Ad esempio, la chiave è “paperino”. Ciò significa che un esterno che dovesse riuscire ad accedere alla password vedrebbe solo qualcosa del tipo “nhc84y9nv8u3ypm6vmmpcw0ct”.

    Dall’altro lato hai l’apparato dotato di microcontrollore (per praticità “uC”). Al suo interno si trova, cablata nel suo firmware, la stessa password del PC, ovvero “pippo&pluto”. In questo caso la password è memorizzata in chiaro (quindi proprio “pippo&pluto”), ma l’attivazione del code protection non permette di vederla dall’esterno (salvo i metodi di cracking HW di cui abbiamo già parlato…. ;-) ).

    Riepilogando, PC ed apparato detengono entrambi la password “pippo&pluto” ma memorizzata in modo in teoria non accessibile.

    Ecco come avviene il riconoscimento:

    1. all’avvio delle due entità, l’utente del software sul PC inserisce la chiave di criptazione, ovvero “paperino”: l’algoritmo crittografico “f” estrae quindi la password in chiaro. Quindi f(nhc84y9nv8u3ypm6vmmpcw0ct) tramite paperino = pippo&pluto;

    2. il software, mediante una funzione di hashing (chiamata “g”), calcola un codice che identifica univocamente la password, ad esempio “bt2785v45t4m985tu” (il bello della funzione hash è che non può essere invertita, quindi g(password)=codice ma g^-1(codice) != password ) . Quindi g(pippo&pluto) = bt2785v45t4m985tu ;

    3. il PC invia al uC un “challenge” ovvero un messaggio in cui dice sostanzialmente: “Adesso calcola tu l’hash della password è vediamo se il calcolo è venuto uguale al mio”. Quindi il uC calcola l’hash della password (che ricordo ha memorizzata in chiaro) . Dunque g(pippo&pluto) = bt2785v45t4m985tu (perchè l’hash di una stringa è univoco…);

    4. il uC invia l’hash al PC, quest’ultimo lo confronta con quello che aeva calcolato esso stesso. Se sono diversi, si chiude subito la connessione, altrimenti se risultano uguali siamo in presenza di due entità realmente “made in Elisabetta”;

    5. da questo momento lo scambio di dati è sicuro e si inizia ad inviare l’ID dell’apparato nonchè del pulsante premuto.

    In questo modo, in “rete” non circolano mai password sniffabili ma solo hashcode (quindi inutilizzabili), nel uC la password è protetta da lettura (come del resto tutto il codice eseguibile del firmware) e nel PC la password è memorizzata in modo criptato. L’unica informazione “sensibile” è la chiave di decriptazione che NON memorizzi nel PC ma solo nella tua testa.

    Fammi sapere se può andare.

    #73387

    elisabetta
    Membro

    Interessante ma mi sfugge qualcosa:
    * il SW “conosce” un pezzo di password (“pippo&pluto”);
    * anche l’apparato “conosce” la stessa password (“pippo&pluto”);
    * l’utente conosce un’altro pezzo di password (“paperino”);
    * ????? anche l’apparato “conosce” (“paperino”)??????;
    * il SW tramite una funzione fa un’operazione qualsiasi sulle due stringhe (funzione “g”) e genera una stringa (MD5?) che non può essere invertita (ovvero “bt2785v45t4m985tu”);
    * il SW invia una richiesta al uC con la quale gli chiede di generare un codice;
    * il uC fa le sue belle operazioni e CON LA STESSA FUNZIONE genera “bt2785v45t4m985tu”, quindi deve conoscere sia “pippo&pluto” sia “paperino” sia “g”;
    * il uC invia il messaggio “bt2785v45t4m985tu” che il SW utilizzera’ per il match. Se coincidono ci troviamo di fronte ad un apparato “made in Elisabetta”;

    Mi vengono in mente alcune considerazioni:
    — ma se io distribuissi 1000 apparati dovrei settare 1000 uC e 1000 “pippo&pluto” in 1000 installazioni del SW (poiche’ all’interno del PC, dopo l’installazione, deve trovarsi il primo pezzo della password)?
    — il fatto di far calcolare il messaggio “bt2785v45t4m985tu” al microcontrollore uC viene scelto poiche’ una “lettura” del uC restituirebbe “pippo&pluto”, probabilmente anche “paperino” nonche’ l’intera funzione “g” che anche il uC deve utilizzare. Non ne comprendo il vantaggio, visto che non ci stiamo curando del cracking.
    — sbaglio o il uC, se interrogato, restituira’ SEMPRE il codice “bt2785v45t4m985tu” che quindi non e’ soggetto a variabilita’?

    Il tuo ragionamento mi piace (al netto di capire se la parola “paperino” di cui sopra debba essere scolpita nel uC) e vorrei proporti una variante.
    Dimmi se fattibile.
    — l’utente non deve conoscere niente;
    — il SW conosce “pippo&pluto” cosi’ come il uC;
    — il SW, poco prima di generare il codice non invertibile, genera una stringa casuale “H8JkK4″ e la passa al uC;
    – il uC e il SW (che usano la stessa funzione “g” non invertibile, ad es. MD5) fanno un’operazione complessa a piacere sulle due stringhe (per semplicita’ ipotiziamo che esse vengano concatenate ottenendo “pippo&plutoH8JkK4″) e usano questa stringa come parametro della funzione “g” ottenendo “IUG346HY0U8W609EF467FW”;
    — il uC, invocato dalla stringa casuale “H8JkK4″, restituisce “IUG346HY0U8W609EF467FW” che e’ sta stessa generata dall’applicazione;
    — siamo sicuri di essere dinanzi ad un “made in Elisabetta” senza dover demandare all’utente alcunche’ e rendendo inutile lo sniffing sulla comunicazione USB (a meno di non conoscere come verra’ concatenata la stringa casuale “H8JkK4″ e la funzione “g”).

    In questo modo FORSE non mi devo preoccupare di modificare 1000 uC e 1000uC poiche’ i dati che essi si passano, al netto di una base comune, sono sempre differenti.

    Credi sia fattibile?
    E se “si”, potresti darmi un’idea di quali componenti mi servano?

    #73388
    delfino_curioso
    delfino_curioso
    Partecipante

    Alcuni chiarimenti.
    Nella mia proposta le due entità non detengono pezzi di una password ma la password intera.
    La differenza sta nel fatto che nel uC è memorizzata in chiaro, mentre nel PC è memorizzata criptata.
    Nell’esempio, “paperino” è la chiave di criptazione, ovvero l’informazione intermedia con cui l’algoritmo di criptazione prende “pippo&pluto” e la trasforma in “hf2t2bgty8nfj4″ (e, viceversa, prende “hf2t2bgty8nfj4″ e la trasforma in “pippo&pluto”).
    Il senso di avere memorizzata nel PC una password criptata è che un malintenzionato che dovesse riuscire a leggerla nel tuo software non vedrebbe “pippo&pluto” ma solo un mucchio di caratteri inutilizzabili (a meno di non possedere la chiave “paperino”, per l’appunto da NON memorizzare nel PC). E’ solo nel momento in cui inserisci nel PC la chiave “paperino” che il software può estrarre la password ed avviare tutto il processo di generazione dell’hashcode che ho descritto successivamente (di conseguenza “paperino” serve solo al PC).

    Ripeto i passaggi sperando siano ora più chiari:

    1. il PC conosce “pippo&pluto” ma la tiene memorizzata come “hf2t2bgty8nfj4″
    2. all’avvio del software, l’utente inserisce la chiave “paperino” ed in quel momento il software converte “hf2t2bgty8nfj4″ in “pippo&pluto”
    3. tramite una funzione hash “g”, il software prende “pippo&pluto” e calcola la sua codifica hash, ad esempio “yih7u8″
    4. il PC chiede al uC di calcolare mediante la funzione “g” la codifica hash della password (il uC conosce la password “pippo&pluto”, la tiene memorizzata in chiaro): il uC calcolerà quindi “yih7u8″ e la invierà al PC
    5. il PC confronta le due codifiche e decide se avviare la comunicazione con il uC o chiuderla.

    Difetti di questa soluzione: sei vincolato a dover inserire la chiave per poter utilizzare il software ed il uC; devi criptare la password in ogni istanza del software del PC

    Pregi di questa soluzione: chi accede al tuo PC non vede la password in chiaro ma solo criptata (quindi inutilizzabile); al uC non si può accedere per via del code protection; sniffando il traffico sulla porta USB vedresti solo codifiche hash della password, da cui non si può risalire alla password stessa, quindi non hai modo di avviare la comunicazione tra PC e uC .

    Detto ciò, non nego che ci possa essere della scomodità nella mia proposta e sono certo che si possa fare di meglio.
    La tua idea di introdurre un elemento di casualità nella generazione delle stringhe hash da confrontare è ottima, poichè porta di fatto a non restituire sempre uno stesso codice.
    Resta però la questione della memorizzazione di “pippo&pluto” nel PC. Se la tieni memorizzata in chiaro (in un file o direttamente in una variabile del codice sorgente) e qualcuno la sgama, poi ottiene il controllo sia del software che del uC nonostante la parte di codifica casuale. Ecco il perchè della mia proposta di criptarla con chiave da inserire “on demand”. Ovviamente questo discorso decade se decidiamo di escludere a monte un’ipotesi del genere…..

    Circa i componenti, non ci sono problemi nel darti un’idea. Tuttavia io al momento me ne preoccuperei meno: a mio parere forse conviene prima capire quali metodi di sicurezza vuoi adottare(crittografia, hashing, entrambi etc.). Da ciò discenderà poi in modo quasi “naturale” che tipo di uC utilizzare, quale compilatore per il firmware, quali strumenti di programmazione a livello hardware etc etc.

    #73390

    elisabetta
    Membro

    Insomma… si aprono diversi scenari :-)

    Lavorando su un prototipo di base, che riceva un messaggio via USB dal PC, che faccia un calcolo X sfruttando una funzione/routine cablata, che produca un output…. di quali componenti avrebbe bisogno?

    #73394
    delfino_curioso
    delfino_curioso
    Partecipante

    Breadboard;
    porta mini-USB femmina;
    microcontrollore con interfaccia USB integrata (per gestione segnali di controllo e calcoli logici semplici va bene un PIC, ad esempio un 18F4550; per calcoli un po’ più spinti, come le funzioni hash, forse conviene andare su un PIC24 o un PIC32);
    pulsanti (per il prototipo vanno bene i micro-switch);
    quarzo, condensatori, resistori appropriati al microcontrollore scelto;
    programmatore HW per il microcontrollore;
    compilatore per il firmware del microcontrollore;
    tanta pazienza;

    :-)

Stai vedendo 13 articoli - dal 1 a 13 (di 13 totali)

Devi aver eseguito l’accesso per poter rispondere a questa discussione.