jump to navigation

Imparare a programmare January 31, 2006

Posted by laspinanelfianco in Programmazione.
19 comments

Fino a qualche anno fa, programmare era un mestiere rivendibile, a volte persino ben pagato. Dal 2001 a questa parte le cose sono molto cambiate, sia a causa dell’esplosione della bolla speculativa sulla new economy che per altre ragioni. Come conseguenza di questo, ora farei molta fatica a consigliarvi di imparare a programmare (od a fare molte altre cose legate all’informatica) come attività di “sviluppo della professionalità personale”. Tuttavia, c’è ancora una ragione molto seria per cui dovreste imparare a programmare un computer se ancora non lo sapete fare: è il modo migliore per capire, una volta per tutte, come funziona un computer dietro le quinte. Dato che dovrete comunque avere a che fare con questi diabolici aggeggi, conquistare questo grado di conoscenza è comunque un vantaggio.

Ma come si impara a programmare? Quale linguaggio è meglio usare? Su quale piattaforma? E con quale ambiente di sviluppo? Qui di seguito trovate le mie personalissime risposte a queste domande.

Come si impara a programmare

Orientativamente, la procedura “corretta” è la seguente.

  1. Si decide su quale piattaforma si vuole lavorare, con quale linguaggio e quale ambiente di sviluppo (vedi sotto).
  2. A computer rigorosamente spento (meglio se dovete ancora comprarlo), si legge (senza studiarlo) un manuale introduttivo adeguato. Lo scopo di questa operazione è quella di farsi una prima idea di massima dell’ambiente che si deve affrontare.
  3. A computer acceso, si comincia con scrivere qualche semplice esercizio fornito dal libro, diciamo i primi 2 o 3.
  4. Una volta capito come si tratta un piccolo programma di 10 o 12 righe, si cerca di sviluppare un piccolissimo programma di propria progettazione, diciamo un aggeggino che apre un file di testo, sostituisce tutte le ricorrenze di “governo” con “manica di ladri” e salva nuovamente il file, magari con un nuovo nome.
  5. Una volta capito come si costruisce un programmino generico come questo, si torna sui libri, questa volta su un manuale più serio e più approfondito. Lo scopo è quello di cominciare a conoscere la piattaforma su cui si sta lavorando (vedi sotto).
  6. Ci si sceglie un “tema” (interfacce grafiche, networking, text processing, quello che vi pare) e si cerca di sviluppare un programma di quel tipo.
  7. Da qui in poi, solitamente, si è in grado di procedere da soli.

Tutto questo almeno in teoria. In realtà, ogni programmatore segue una propria strada per imparare. Pensare che una strada sia migliore di un’altra sarebbe segno di stupidità e di intolleranza. Sentitevi liberi di fare come vi sembra meglio.

Quale linguaggio

Sto per dire una cosa per cui verrò scorticato vivo ma devo comunque dirvela: ci sono alcuni linguaggi che, in questa prima fase della vostra carriera di programmatori, dovreste evitare accuratamente. Li elenco qui di seguito, spiegando il motivo per cui non dovreste usarli.

Basic (e soprattutto M$ Visual Basic): Viene suggerito agli utenti alle prime armi dicendo loro che è “semplice”. Nella realtà è molto più complesso ed irregolare di altri linguaggi e, nel caso di Visual Basic è molto, molto più complicato del necessario (e del ragionevole) a causa della costruzione delle interfacce grafiche (GUI), da cui non è praticamente possibile prescindere. Come se non bastasse, permette di fare la stessa cosa in molti modi diversi. Questo vuol dire che una persona che legge il codice di un’altra spesso non riesce a capire cosa faccia quel codice a causa delle diverse “abitudini” di programmazione. Persino la stessa persona, che rilegga il proprio codice a distanza di settimane o di mesi, può trovarsi in difficoltà. (In realtà, in VisualBasic si possono creare programmi privi di interfaccia grafica ma tutta la pressione dell’ambiente tecnico/sociale del VB va verso la creazione di programmi GUI-based.)
Perl: Valgono tutte le considerazioni appena fatte per il Basic. Per fortuna, Perl non vi obbliga da subito a trattare con le interfacce grafice.

Java: Java è molto semplice ed elegante, al punto che viene largamente utilizzato nelle scuole superiori e nelle università per insegnare a programmare. Tuttavia, devo sconsigliarvelo (anche se siete professori e lo usate per insegnare!). Il motivo è che Java costringe il programmatore ad organizzare il codice in maniera piuttosto fiscale ed innaturale (una classe per ogni minima cazzata, un file per ogni classe, un archizio compresso per ogni progetto, etc.) e questo introduce nel discorso “programmazione” un elemento di “gestione del file system” che francamente non è proprio necessario. Ci sono linguaggi, come Python, che offrono gli stessi vantaggi di chiarezza ed eleganza e non rompono i coglioni in questo modo.

La mia personalissima e discutibilissima opinione è, che per cominciare (ed anche “per finire”), dovreste usare Python.

Python: Python è un linguaggio molto simile a Java ma che non impone nessuna delle follie organizzative di Java. Python è talmente semplice ed elegante che viene largamente ritenuto dagli specialisti “il” linguaggio con cui insegnare a programmare (o con cui imparare a programmare da soli). Python è molto simile a C, il linguaggio più usato in assoluto per la programmazione professionale, e quindi è un ottimo modo di prepararsi alla carriera da professionista.

In ogni caso, tutti i linguaggi che abbiamo citato sono linguaggi interpretati: i programmi che si possono scrivere con questi linguaggi richiedono l’interprete installato sulla macchina per l’esecuzione. Non possono funzionare da soli. In altri termini, un programma Python deve essere lanciato in questo modo:

python mioprogramma.py parametro1 parametro2

Non può essere lanciato senza l’interprete, in questo modo:

mioprogramma.py parametro1 parametro2

(Questo non è del tutto vero ma per il momento fate finta che lo sia). Questo comporta un vantaggio ed uno svantaggio: il vantaggio è che il vostro programma gira dovunque sia disponibile l’interprete, lo svantaggio è che è leggermente più lento di un programma C. Un programma Python può essere scritto ed eseguito su queste piattaforme:

  • Windows (tutte le versioni)
  • McOS (Tutte le versioni)
  • Unix (Tutte le versioni)
  • Linux (Tutte le versioni)
  • BSD (Tutte le versioni)

Non pensiate che Python sia un linguaggio per studenti o che sia in qualche modo limitato: dispone delle librerie necessarie per trattare qualunque (dico proprio qualunque) problema che si possa presentare nella vita professionale, dalla creazione di interfacce grafiche con vari toolkit su qualunque (ripeto qualunque) piattaforma fino alla creazione di interpreti di linguaggi. Python viene usato da molti anni da schiere di programmatori professionali che con esso hanno creato una moltitudine di programmi di ogni tipo, alcuni dei quali sono persino dei successi commerciali (come Komodo di theKompany). Da ogni punto di vista, è un rispettabile linguaggio di programmazione professionale come il C, solo che è interpretato.
Quale piattaforma

Quasi certamente state usando Windows, in una delle sue molte versioni. Lo posso dire con una buona probabilità di prenderci perchè Windows occupa ben il 93% del mercato. Restate fedeli a Windows, se vi trovate bene.

Se non vi trovate bene con Windows, passate a Linux o BSD (FreeBSD, OpenBSD o NetBSD). Questo vi costerà un po’ di fatica ma ne vale la pena.

Se siete fortunati possessori di un MacIntosh, restategli fedeli. Se non ne possedete uno, non fate la voglia inutilmente: installate Linux conKDE o Gnome e non pensateci più.

La piattaforma sui cui è in assoluto più semplice e più gradevole programmare è probabilmente Linux, per molte ragioni. Tuttavia, tenete presente che su Windows e su MacIntosh sono disponibili degli ambienti di sviluppo veramente molto raffinati e molto avanzati che su Linux non sono disponibili, in particolare, su Windows è disponibile (a pagamento) il fantastico ambiente “Visual Studio” di M$.

Quale ambiente

L’ambiente di lavoro, noto come IDE (Integrated Development Environement) è un programma che include tutto il necessario per scrivere codice e che, soprattutto, si occupa della manutenzione dei “progetti” (l’insieme dei file che scrivete). Un buon IDE può semplificare di molto la vita ad un programmatore, soprattutto se inesperto (o terribilmente pigro, come me).

Su Windows, lo abbiamo detto, esiste la Rolls-Royce degli IDE: il gigantesco, potentissimo e raffinato “Visual Studio” di M$. Costa come uno scooter, e nei primi 3 mesi vi farà impazzire, ma può valere la pena imparare ad usarlo se pensate di programmare a livelli non solo dilettanteschi.

Ambienti come questi esistono anche su MacIntosh ma per questo dovete chiedere consiglio a qualcuno che usa MacIntosh. Io non ho pratica di questo ambiente.

Su Linux (e su tutti gli Unix) sono disponibili vari ambienti di sviluppo molto raffinati, tra cui il mitico “meta-IDE” “Eclipse” di IBM ed il raffinato “KDevelop” di KDE. Sono tutti piuttosto validi.

Il mio personalissimo consiglio è che stiate alla larga dagli IDE per i primi mesi e vi limitate ad usare un editor di testo (NotePad o simili). Dopo aver capito come si programma, provate i due o tre IDE più diffusi nel vostro ambiente e scegliete quello che vi piace di più.

Personalmente, ne ho provati diverse dozzine nell’arco di molti anni ed alla fine ho deciso di usare… KEdit di KDE (Su Linux), un piccolo e scarno editor di testo simile a NotePad di MS Windows.

Altri consigli

Non lavorate da soli: se vi è possibile, cercate di lavorare con un amico od almeno iscrivetevi ad una mailing list di programmatori e restate in contatto con loro.

Non ponetevi obiettivi prima di 6 mesi: lo so che fremete dalla voglia di fare qualcosa di vostro ma cercate di avere pazienza. Ci vuole un po’ di esperienza prima di maturare la competenza necessaria per mettere in cantiere un progetto orginale. Tentare di farlo prima del tempo può portarvi ad un fallimento frustrante e farvi passare la voglia di imparare.

Tenete presente che qualunque progetto di un qualche interesse reale richiede molto, a volte moltissimo lavoro e quindi sarete quasi certamente costretti a trovarvi almeno un compagno di avventura.

Leggete molto: gran parte del problema della programmazione è in realtà un problema legato alla conoscenza della piattaforma (Windows o Linux) e delle tecniche di programmazione specifiche dei vari ambienti (text processing, GUI, networking). Per questo è importante leggere molto.

Il modo in cui si studia in informatica è qualcosa che probabilmente farebbe inorridire molti professori di fisica o di matematica ma per fortuna è molto piacevole: si tratta quasi sempre di curiosare nei libri e nei siti web seguendo il filo delle proprie esigenze, senza farsi problemi di organicità delle conoscenze apprese. Rovistate dentro il web senza farvi troppi problemi e fate qualche esperimento pratico. Dopo poco vi renderete conto da soli di cosa vi serve e di come dovete organizzare le vostre conoscenze.
Questo è tutto. Nella pagina “libri” troverete presto qualche titolo interessante per approfondire.

Emulare il Fritz Chip January 31, 2006

Posted by laspinanelfianco in Trusted Computing.
1 comment so far

Dato che il Friz Chip (TPM), è il cuore del Trusted Computing e fornisce tutte le funzionalità crittografiche necessarie al resto dell’architettura, non sarebbe possibile “fregare” tutto il sistema semplicemente emulando questo componente con un apposito programma?

Questa è una delle domande a cui per diverso tempo non sono riuscito a dare una risposta chiara e definitiva. La difficoltà non risiede tanto negli aspetti tecnici del TC, tutto sommato abbastanza chiari, quanto nella strategia di comunicazione delle aziende coinvolte in questo progetto. Come spesso avviene quando si studia il TC, bisogna dedurre le risposte alle proprie domande da quel poco che viene detto (e soprattutto da quello che non viene detto) nei soporiferi documenti tecnici del TCG. Una volta distillata l’informazione in questo modo, tuttavia, la risposta è dolorosamente chiara.

L’ipotesi del cracking per emulazione

In ultima analisi, il Fritz Chip è soltanto un componente hardware come la scheda video o la scheda di rete. Questi dispositivi hardware possono essere emulati da appositi programmi, in modo che il software che ha bisogno di loro possa funzionare tranquillamente anche in loro assenza. L’emulazione è una pratica comune nel mondo dell’informatica e non presenta particolari problemi teorici. Avendo a disposizione una “macchina di Turing completa” (un normale computer) è possibile emulare in tutto od in parte un ambiente operativo con una precisione tale da fare credere al software di vivere letteralmente in un altro mondo. Sul mercato sono presenti numerosi esempi di emulatori software di questo tipo, da VMWare a Boch, a QEMU, a VirtualPC a SoftPC a Xen. Tutti questi emulatori mostrano ai programmi applicativi le immagini virtuali di schede di rete, schede audio e video, intere CPU e persino intere reti emulate via software. In tutti questi casi, un programma applicativo che gira nell’emulatore crede veramente di trovarsi all’interno di un PC costruito e configurato secondo le sue esigenze, anche se la macchina su cui si trova è completamente diversa. In questo modo è possibile installare ed eseguire Linux per Intel all’interno di un PC virtuale emulato da VMWare su una macchina Apple-Motorola, ad esempio.

L’aspetto più interessante dell’emulazione è che il software non è in grado di scoprire se sta girando nel suo ambiente abituale o nell’emulatore. Per poterlo fare dovrebbe avere un punto di riferimento esterno all’emulatore, cioè qualcosa che l’emulatore non possa falsificare, grazie al quale effettuare qualche tipo di verifica.

Il problema della chiavi

Nel caso del TPM, questo elemento esterno e non falsificabile esiste: sono le chiavi crittografiche RSA, pubblica e privata, a 2048 bit che identificano in modo univoco il Fritz Chip. Queste chiavi vengono generate durante la produzione del chip dal chip stesso e vengono memorizzate al suo interno. In questa loro forma autocontenuta, non sono quindi di nessuna utilità: l’emulazione del Fritz Chip si limiterebbe ad emulare anche le chiavi insieme a tutto il resto. Per essere utili, queste chiavi devono essere registrate in un database esterno, in modo che il software applicativo possa usare questo database per verificare se il Fritz Chip è stato veramente prodotto da una industria, secondo i criteri desiderati, od è invece una emulazione software del tutto inaffidabile.

Ma questo database esterno, esiste o no?

Cosa dicono i documenti

Questo è il punto in cui occorre rileggere varie volte i documenti del TCG, di Intel e di M$ per riuscire ad avere una risposta chiara e definitiva.

I documenti ufficiali del Trusted Computing Group glissano elegantemente su questo dettaglio. Viene prevista la generazione e la memorizzazione delle chiavi sul chip ma non viene specificato che cosa debba essere fatto di queste chiavi da parte del produttore. La decisione di memorizzarle in un database esterno viene lasciata al produttore. Una posizione simile viene mantenuta anche da Intel nei documenti di LaGrande Technology. Intel si limita a dire che userà un Fritz Chip (saldato sulla motherboard o integrato nella CPU) per questo scopo. M$ è solo leggermente più esplicita e sostiene che il software abilitato a girare su Windows Vista con NGSCB sarà soggetto a qualche forma di certificazioni.

Per avere una risposta chiara bisogna ricorrere al documento “Clarifying misinformation on TCPA” di David Safford. Ecco come Safford risponde ad un commento di William Arbough:

“Both [integrity protection and trusted storage] use trusted root certificates as this basis [of their security guarantees.]”

This is a misunderstanding of the TCPA specification. There is no requirement for certificates at all, to use any TCPA chip function. There doesn’t even exist such a root authority for TCPA in general, or for IBM’s currently shipping chips. You can generate private keys, use them to sign, and decrypt, and seal/unseal data under PCR’s, all without any certificates. The only time a certificate is needed is if you want to be able to prove to a third party that you have an approved TCPA chip. Most applications do not have this need, and this certification is not currently supported with IBM’s chips. If you want to do an application that needs such a certificate, the TCPA has an endorsement key that can be used to get a suitable certificate. The only way this can work is if someone, like the manufacturer, has recorded a given TCPA chip’s public endorsement key, and can use this knowledge to certify identity keys from the given TCPA chip. This is not required, and software access to the endorsement key can be disabled. There is certainly a privacy aspect of access to the endorsement key, as it uniquely identifies the platform, and the TCPA specification goes to great lengths to allow for anonymous certification. The best defense for privacy conscious users is simply to turn off the endorsement key.

Tradotto alla meglio, questo frammento di testo dice:

“Il Trusted Computing usa dei certificati come base della sua sicurezza.”

Non sono richiesti certificati per nessuna delle funzioni del TPM. Non esiste nemmeno una autorità in grado di rilasciare questi certificati a livello globale od a livello del produttore (IBM). Potete generare chiavi, cifrare e decifrare materiali, firmarli e verificarli senza nessun bisogno di certificati. L’unico caso in cui avete bisogno di un certificato di questo tipo è se dovete mostrare ad una terza parte che state utilizzando un TPM “approvato”. La maggior parte delle applicazioni non ha bisogno di questa garanzia e questo tipo di certificazione non è attualmente supportato da IBM. Se volete creare una applicazione che sfrutti questa possibilità, il TPM ha una apposita endorsement key che può essere usata a questo scopo. L’unico modo in cui questo sistema può funzionare è che il produttore del chip abbia registrato la chiave pubblica del chip e renda disponibile questa conoscenza per verificare l’identità del chip stesso. Questa è una funzionalità che non è richiesta dalle specifiche e comunque l’accesso del software alla endorsement key può essere disabilitato. Esiste certamente un problema di privacy legato alle endorsement key, dato che possono identificare univocamente il chip ed il suo utilizzatore. Per questo motivo le specifiche del TCG si sforzano così duramente di permettere una qualche forma di certificazione anonima. La migliore difesa da questo tipo di minacce alla privacy è semplicemente quella di disabilitare del tutto le endorsement key.

Conclusioni

Da questo frammento di testo di Safford si riesce finalmente a stabilire cosa ne è di queste chiavi. In realtà, da questo frammento di testo si possono raccogliere anche altre informazioni interessanti. Le riporto qui di seguito.

  • Le chiavi necessarie per impedire un approccio cracking-by-emulating esistono sempre (per specifica tecnica).
  • La loro memorizzazione, necessaria per la riuscita dell’operazione di contrasto, viene lasciata alla discrezione del produttore, in modo che il TCG possa difendersi più facilmente dalle inevitabili accuse relative alla violazione della privacy.
  • Le aziende, ovviamente, memorizzeranno queste chiavi e le renderanno disponibili ai produttori di software che vorranno fare questi controlli. Se non agissero in questo modo, uno dei principali vantaggi del TC andrebbe perso.
  • Safford stesso è costretto ad ammettere che queste chiavi rappresentano una minaccia per la privacy.
  • Safford stesso è costretto a riconoscere che l’unica vera difesa da questa minaccia è quella di disabilitare completamente le chiavi.

A questo punto, possiamo rispondere alla domanda iniziale: no, non è possibile fregare il sistema emulando il TPM. Il TPM può essere facilmente emulato (ne trovate un esempio qui: http://tpm-emulator.berlios.de/ ) ma l’emulazione non risolve il problema e non permette di crackare le difese.