It’s night, your home is silent. Your appliances quietly talk to each other, while MQTT messages run in your wifi network towards a distant broker, carrying both unassuming payloads like your bedroom temperature or the washing machine power consumption and more sensitive ones, like your alarm system sensors status.

The problem is that what to your appliances looks like one of your routers is not, in fact, one of your routers. Someone hijacked your network with a simple tool he bought on the internet for a handful of euros. That little guy is sending all your packets to his owner, who simply ignores your fridge and oven chatters but focuses on the data sent from the security sensor of your back door. The rest is a nightmare.

The Internet of Things, whatever it means these days, is a great opportunity for good and bad guys alike. The wealth of data transmitted among “Things” must be protected from prying eyes just like your emails and home banking transactions do. Some times, even more.
What you need is cryptography, the technique humans always used and refined to keep things secret, from the Pharaos to the NSA. Encrypting messages payloads could keep most of the bad guys outside your network, and your home.
The problem is that IoT devices must be kept small in terms of computing and memory resources in order to get low power consumption and acceptable costs, but this does not go well with the intricacies and calculation requirements of modern cryptography techniques.
To be suitable for use in a low power, single chip device, a crypto algorithm (indeed, a library of implementations of cryptographic algorithms) must be reasonably secure both in the algorithms themselves and in the code that implements them; it must work as fast as possible to avoid getting in the way of the job that the IoT network must do and to consume a small quantity of processing power and finally it must require the smallest memory footprint possible.

Writing such a library is a daunting task, well beyond the skills and time to market requirements of the vast majority of IoT developers. A properly written, fast and simple library, to really be secure, must also be easy to use: cryptography is a tricky matter, often learnt in higher level math courses. Using a secure but complex library in an inappropriate way could open dangerous vulnerabilities in your code and protocols.

The Mountaineer Group tries to come in help proposing a porting to c# for the .NET microframework of the widely known (and very positively reviewed) NaCl (pronounced “salt”) crypto library, written by Daniel J. Bernstein and Tanja Lange http://nacl.cr.yp.to/.  The engineers at Oberon have chosen an implementation from the original C code of each NaCl algorithms, they’ve built the necessary plumbing between the NaCl lib and the C# API, trying to mimic as closely as possible the original function signatures, and shared the library for review.  Little differences in data types still remain, but this should not hinder the overall safety and ease of use of the methods.

(more…)

Chi segue gli sviluppi e l’evoluzione dei sistemi per quella che viene denominata “Internet-delle-cose” (IoT, Internet of Things), sa che uno degli aspetti più intriganti riguarda la possibilità di supervisionare (ossia osservare ed agire) sistemi fisici remoti. Le piattaforme più interessanti in tal senso, Pachube e ThingSpeak, forniscono l’infrastruttura di base per una comunicazione bidirezionale, strutturata tipicamente intorno a interfacce REST/JSON, con cui i client (web, app, servizi, ecc.) interagiscono da remoto con device elettronici che a loro volta fanno capo a sensori, motori, sistemi di comunicazione periferici, ecc.

Quello che di fatto però servizi quali Pachube e ThingSpeak non permettono, per motivi legati agli inevitabili compromessi tra costi di infrastruttura e valore dell’implementazione, sono il controllo del sistema fisico veramente in real-time, ossia quello che scherzosamente ho chiamato nel titolo “real-real-time”, in cui ogni azione svolta sul sistema da remoto, ogni variazione autonoma dello stesso così come ogni notifica di variazione vengono gestite in tempi inferiori al decimo di secondo, oltre il quale l’utente perde la percezione di “tempo reale”.

Se ci poniamo come obiettivo inoltre quello di utilizzare client realizzati come applicazioni web in senso tradizionale, ossia che non utilizzino naturalmente un modello di messaging “push”, le scelte tecnologiche possibili restano poche, anzi pochissime: Flash (poco portabile soprattutto in ambito mobile), Silverlight (anch’esso un po’ troppo vincolante come potenziale platea di client), WebSockets (non ancora stabili né implementati completamente nella maggior parte dei browser, mobile e non), Applet Java (praticamente scomparse dal web e comunque poco portabili sulle nuove piattaforme) e, l’attuale miglior candidato, lo straordinario SignaR.

Senza addentrarci nei dettagli, per i quali vi rimando al Wiki del progetto su GitHub e ad un post di “recensione” di Scott Hanselman, SignalR è un framework per ASP.NET (lato server) e HTML+JS, .NET4 e WP7 (lato client) che implementa il supporto per la comunicazione bidirezionale tra client e server. Sfruttando un modello costruito intorno ai tipi “dynamic”, SignalR rende ad esempio possibile chiamare un metodo di una classe server-side da parte di uno script JavaScript e, decisamente più stupefacente, chiamare una funzione JavaScript del client da parte del server! Quello che è ancora più interessante è che SignalR semplifica in maniera imbarazzante la creazione di “concentratori” (chiamati Hub) che, oltre a ricevere chiamate dai client,  possono diramare in broadcasting messaggi a tutti i client collegati a quell’Hub.

Nell’esempio che ho realizzato, finalizzato proprio al controllo di N uscite digitali, N ingressi digitali e N ingressi analogici di un sistema, ho creato un Hub SignalR che comunica, con la mediazione di un oggetto Singleton che serializza le comunicazioni che per loro natura sarebbero parallele proveniendo da più client simultaneamente, con una scheda .NET MF (un FezPanda-II con collegati 2 led, un pulsante e un potenziometro) via Socket TCP/IP, bidirezionale e full-duplex per natura.

L’applicazione client è costituita da una singola pagina ASPX che contiene il pochissimo markup relativo ai due pulsanti per il toggling delle uscite digitali e ad un <div> per ciascuna delle grandezze rilevate (gli stati del pulsante, dei led e del potenziometro) e una cinquantina di righe di JavaScript per la attivazione dell’Hub SignalR e per il processing dei messaggi scambiati con il server. Nella sua attuale (e temporanea) implementazione l’applicazione si presenta così, più o meno indipendentemente dal browser (desktop, tablet o smartphone) su cui è stata testata:

 

 

L’abbondanza di nuovo materiale reperibile in rete in tema di “modularità” delle applicazioni Javascript, tipicamente per quanto riguarda applicazioni web particolarmente“client-side” (o addirittura SPA) ma anche per quanto concerne applicazioni NodeJs, unitamente ad iniziative quali TypeScript, dimostrano il bisogno che la moderna comunità degli sviluppatori ha di metodologie e best practices finalizzate alla riduzione del rischio di “spaghetti-code” nella creazione di progetti Javascript complessi, quali quelli che quotidianamente vengono affrontati da chi utilizza questo linguaggio per professione.

Senza addentrarci in temi troppo “accademici”, credo non si possa negare che gli elementi più critici in tal senso sono due:

• Scarsa propensione all’OOP
• Difficoltà nella gestione delle dipendenze

Quanto al primo punto, in realtà non si può dire che Javascript non sia un linguaggio object-oriented, anzi al contrario lo è, ed addirittura molto più di altri (anche le funzioni sono oggetti, ad esempio); quello che con più esattezza motiva la scarsa propensione ad essere utilizzato come linguaggio adatto all’OOP è semmai la sua peculiarità ad essere più “object-oriented” che “class-oriented” (o “type-oriented”), cosa che di fatto mette a disagio chi ha più dimestichezza con linguaggi quali C++, Java e C#, caratterizzati da un paradigma effettivamente molto differente.

In merito al secondo punto, se facciamo ad esempio riferimento ad una applicazione web più o meno tipica, non possiamo non notare come l’inclusione di 10-15 script “*.js” fatta da parte dei vari frammenti di markup HTML che popolano ciascuna pagina/vista dell’applicazione ha l’effetto di “inquinare” (non a caso si parla di “namespace pollution”) lo spazio in cui operano gli oggetti attivi all’interno dell’engine (che sia quello interno al browser o quello definito in nodejs) che sta eseguendo la nostra applicazione, senza considerare l’intricato rapporto di dipendenze che molto spesso esiste tra gli script in questione.

Sebbene non mi senta di dire che si tratti della soluzione “ottima” o “definitiva”, ho trovato particolarmente efficace la soluzione illustrata di seguito, in cui il primo punto critico è affrontato utilizzando un pattern per la traduzione dei concetti tipici di un linguaggio OOP quale Java, C++ o C#, mentre il secondo viene sostanzialmente risolto mediante l’adozione del cosiddetto “Module-pattern” (nella “accezione” AMD, più precisamente), reso per l’occasione meno “complicato” dall’utilizzo del framework RequireJS, che sta di fatto diventando uno standard infrastrutturale anche in molti framework più “verticali”.

Per rendere l’illustrazione di questo approccio più eloquente possibile, direi di utilizzare l’esempio che segue, costituito dalla seguente struttura di file:

• default.htm
• scripts (dir)
  • scripts/main.js
  • scripts/person.js
  • scripts/student.js
  • scripts/require.js

Il file default.htm, un po’ scarso nella sua espressione puramente UI dal momento che tutto l’output del demo si svolge all’interno della console del browser, è il seguente, in cui è evidenziata la parte di dichiarazione delle dipendenze gestita da RequireJS:

Lo script person.js è il seguente:

Mentre Student.js è il seguente:

Per verificare il funzionamento del tutto possiamo utilizzare un main.js come quello che segue:

Così facendo, dovremmo ottenere un output di questo tipo:

Per approfondimenti:

https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript

http://phrogz.net/JS/classes/OOPinJS.html

http://phrogz.net/JS/classes/OOPinJS2.html

http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth

https://github.com/amdjs/amdjs-api/wiki/AMD

http://requirejs.org/docs/start.html

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is y

 

our first post. Edit o WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first pos
t. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or d

elete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
Welcome to WordPress. This is your first post. Edit or delet
e it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogg

 

ing!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then
start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!v