- nexa - server-nexa.polito.it

Re: [nexa] Centralized or Decentralized?, The Contact Tracing Dilemma
by Giacomo Tesio May 21, 2020

May 21, 2020

On Thursday, 21 May 2020, Giovanni Biscuolo <giovanni(a)biscuolo.net> wrote: > Buongiorno Massino > > ma evidentemente sono io che sono un brontolone :-) Io ho l'impressione che uno dei pochi lasciti positivi del covid19 potrebbe essere la presa di coscienza da parte dei politici della rilevanza politica dell'informatica, del potere che rappresenta. Alcuni iniziano persino ad intuire la propria inadeguatezza a parlarne. Non hanno ancora del tutto chiaro la portata del problema e naturalmente tendono a minimizzarla per convivere con tale inadeguatezza, trattando la materia come una qualsiasi disciplina specialistica di cui non sanno nulla. Il problema è che non si tratta di una disciplina specialistica, più di quanto non lo sia la matematica. E non ne sanno nulla. Però in questo periodo il problema è così enorme ed evidente che non può essere ignorato. Nonostante tutto il lavoro di UI ed UX, che punta a far diventare il mezzo invisibile, nessuno può ignorare che c'è e non è affatto neutrale. Per quanto triste, per quanto falso, per quanto folle, un Ministro che si sottomette pubblicamente (umiliando lo Stato che rappresenta) al capriccio privato (e USA-centrico) dei "colossi del Web" perché "non si può pensare di competere" è un passo avanti. È un buon momento per dire che il re è nudo. Perché i nemici, ben corazzati, sono sotto gli occhi di tutti. E stanno distribuendo gli aggiornamenti. Giacomo

1 0

Centralized or Decentralized?,The Contact Tracing Dilemma
by Massimo Canducci May 21, 2020

May 21, 2020

Vi segnalo questo paper che affronta in dettaglio le differenze (a livello di privacy) dei due modelli in oggetto. Lo trovate integrale qua: https://eprint.iacr.org/2020/531.pdf Un saluto a tutti Max

2 1

International Association of Consitutional Law Blog
by Oreste Pollicino May 21, 2020

May 21, 2020

Se di interesse, un mio post su temi cari alla Lista buona giornata o. https://blog-iacl-aidc.org/2020-posts/2020/5/21/fighting-covid-19-and-prote…

1 0

Articolo Nature su Contact Tracing
by Roberto Dolci May 21, 2020

May 21, 2020

https://www.nature.com/articles/d41586-020-01514-2 Ieri in call con Alex Vespignani e Maurizio Fava ho appreso che la paura non fa 90 ma fa un +12% di maggior compliance nell'uso della maschera ed in generale delle regole di prudenza per il contenimento del corona. Quest'articolo riprende il tema del grado di adozione dello strumento, ed il sentimento di sfiducia verso governo/autorita' Ciao roberto

2 1

Siri, l’assistente vocale Apple non solo risponde ma ascolta - Il Fatto Quotidiano
by J.C. DE MARTIN May 20, 2020

May 20, 2020

https://www.ilfattoquotidiano.it/in-edicola/articoli/2020/05/20/siri-lassis… (Sent from my wireless device; please excuse brevity and typos (if any))

2 1

Inferring distance from Bluetooth signal strength: a deep dive
by Giacomo Tesio May 20, 2020

May 20, 2020

https://medium.com/personaldata-io/inferring-distance-from-bluetooth-signal… In sostanza, Google e Apple cercano di ridefinire il concetto di contact tracing per adattarlo ai cellulari. Ma NON faranno contact tracing, perché non funzionerebbe. Mica scemi! (loro) Giacomo Contact tracing apps intend to predict exposure to a COVID-19 infection, where exposure is computed as some function of time and distance to an infected person. The distance is inferred from Bluetooth signal strength, which is a step that has not been empirically tested properly. We review evidence coming from the developing teams of what might or might not work to deduce distance from Bluetooth signal strength, and eventually question whether this is truly the goal of all those who implement contact tracing apps. [...] # Apple & Google APIs It is very hard at the moment to know how Apple & Google intend to let apps infer distance from signal strength. In fact, every indication seems to be that they don’t intend to do that. They seem to want the apps to instead infer transmission risk from signal strength directly. Caveat: There seem to be changes, between v1.2 (cryptography, Bluetooth) and v1.3.1 (Android) of their protocol that relates to precisely this point. There is certainly divergence between Google and Apple, at least in the documentation available, since Google’s Android API v1.3.1 mentions AttenuationThresholds while iOS’ API doesn’t. For the moment, one thing we can productively evaluate is the core of the API already made available. It shows how the risk calculation will be derived. We include a few screenshots below of Android vs iOS. Android API for configuring the Exposure Risk calculation (taken from Android API v1.2, now superseded by v1.3 which doesn’t include the graphic anymore; v1.3 changes the way attenuationScores are computed) iOS ENExposureConfiguration (no version number available) Note that there are subtle but significant differences between the two: the range of the parameter values start at 0 or 1, and more crucially the final risk is calculated multiplicatively resp. additively. Definition of the parameters presented above, in the iOS API. We see that the attenuation is averaged to just one number, that is then passed to the app. Based on the fact that a simple average is returned instead of the actual sampled signal attenuation values, and all the difficulties outlined above, I infer that the Apple and Google APIs intend only to help apps deduce the infection risk from Bluetooth measurements, and not the distance itself (which could then be fed into epidemiological models). The Apple and Google APIs thus change the definition of the notion of contact for epidemiological purposes. Inferring infection risk from Bluetooth signal strength instead of distance is not a neutral act. Almost everyone is equal in understanding and assessing a recommendation of social distantiation of 2 meters, and able to discuss the politics of remediation for those who are not capable of following this rule. As a society, we also have much more common cognitive basis for discussing the politics tied to manual contact tracing and the consequences that follow from that process (for instance in carefully balancing false positives and negatives in manual contact tracing). With Bluetooth-based proximity tracing leveraging the Google and Apple API, we lose that common cognitive basis. Apple and Google get to define the rules, and will progressively get to introduce new data as input (if indeed, like everyone else, they conclude this is a necessity). It also will lead to a substantive shift in what constitutes a false positive and a false negative.

1 0

Bluetooth BIAS attack threatens billions of devices
by Giacomo Tesio May 20, 2020

May 20, 2020

https://securityaffairs.co/wordpress/103480/hacking/bias-attack-bluetooth.h… "The Bluetooth specification is affected by security flaws..." Non è la prima... non sarà l'ultima. ;-) Giacomo Boffins disclosed a security flaw in Bluetooth, dubbed BIAS, that could potentially be exploited by an attacker to spoof a remotely paired device. Researchers from École Polytechnique Fédérale de Lausanne (EPFL) discovered a vulnerability in Bluetooth, dubbed Bluetooth Impersonation AttackS or BIAS, that could potentially be exploited by an attacker to spoof a remotely paired device. The issue potentially impact over a billion of devices. “To establish an encrypted connection, two Bluetooth devices must pair with each other using a link key. It is possible for an unauthenticated, adjacent attacker to impersonate a previously paired/bonded device and successfully authenticate without knowing the link key. This could allow an attacker to gain full access to the paired device by performing a Bluetooth Impersonation Attack (BIAS).” reads the vulnerability note VU#647177. The Bluetooth specification is affected by security flaws that could allow attackers to carry out impersonation attacks while establishing a secure connection. For BIAS attack to be successful, the attacker has to use a device that would need to be within wireless range of a vulnerable Bluetooth device that has previously established a BR/EDR bonding with a remote device with a Bluetooth address known to the attacker. To establish an encrypted connection, two Bluetooth devices must pair with each other using a link key, aka long term key. The experts explained that the flaw results from how two previously paired devices handle the link key. The link key allows two paired devices to maintain the connection every time a data is transferred between the two devices. The experts discovered that it is possible for an unauthenticated attacker within the wireless range of a target Bluetooth device to spoof the address of a previously paired remote device to successfully complete the authentication procedure with some paired/bonded devices without knowing the link key. “The Bluetooth standard includes a legacy authentication procedure and a secure authentication procedure, allowing devices to authenticate to each other using a long term key. Those procedures are used during pairing and secure connection establishment to prevent impersonation attacks. In this paper, we show that the Bluetooth specification contains vulnerabilities enabling to perform impersonation attacks during secure connection establishment.” reads the research paper. “Such vulnerabilities include the lack of mandatory mutual authentication, overly permissive role switching, and an authentication procedure downgrade.” The researchers reported their findings to the Bluetooth Special Interest Group (SIG), in December 2019. “The researchers identified that it is possible for an attacking device spoofing the address of a previously bonded remote device to successfully complete the authentication procedure with some paired/bonded devices while not possessing the link key. This may permit an attacker to negotiate a reduced encryption key strength with a device that is still vulnerable to the Key Negotiation of Bluetooth attack disclosed in 2019.” reads the advisory published by the Bluetooth SIG. “If the encryption key length reduction is successful, an attacker may be able to brute force the encryption key and spoof the remote paired device. If the encryption key length reduction is unsuccessful, the attacker will not be able to establish an encrypted link but may still appear authenticated to the host.” Experts explained that combining the BIAS attack with other attacks, such as the KNOB (Key Negotiation of Bluetooth) attack, the attacker van brute-force the encryption key and use it to decrypt communications. “The BIAS and KNOB attacks can be chained to impersonate a Bluetooth device, complete authentication without possessing the link key, negotiate a session key with low entropy, establish a secure connection, and brute force the session key” states the paper. Experts tested the attack against as many as 30 Bluetooth devices and discovered that all of them were found to be vulnerable to BIAS attacks. The Bluetooth SIG has addressed the vulnerability announcing the introduction of changes into a future specification revision. The SIG recommends Bluetooth users to install the latest updates from the device and operating system manufacturers. “The BIAS attacks are the first uncovering issues related to Bluetooth’s secure connection establishment authentication procedures, adversarial role switches, and Secure Connections downgrades,” the paper concludes. “The BIAS attacks are stealthy, as Bluetooth secure connection establishment does not require user interaction.”

1 0

Bando CS PNT
by Monica A. Senor May 19, 2020

May 19, 2020

Cari tutti, mi permetto di promuovere in lista, anche quest’anno, l’interessante bando per l’attribuzione di un premio per tesi di laurea magistrale o di dottorato di ricerca su temi legati al rapporto tra protezione dei dati personali e innovazione tecnologica istituito dal Centro Studi Privacy e Nuove Tecnologie. Scadenza imminente: 31 maggio! Buona serata, Monica

1 0

Jennifer Cobbe, Elettra Bietti: Ripensare le piattaforme digitali per l'era post Covid-19
by Roberto Resoli May 19, 2020

May 19, 2020

Non credo sia passato in lista; la necessità di elaborare nuove forme di partecipazione digitale: "Costruire un nuovo ecosistema di piattaforme. È ora più chiaro che mai che dobbiamo ricostruire i legami di comunità, solidarietà e società. Dobbiamo reinventare la nostra società e la nostra economia digitale, con nuove istituzioni, nuove strutture e nuovi spazi di comunicazione e di connessione. Il paradigma della piattaforma per i servizi online non è di per sé un problema, ma dobbiamo ripensare radicalmente il modo in cui le piattaforme sono organizzate e il loro funzionamento. Questo passo, naturalmente, è solo il primo di molti nel processo di riforma strutturale della gestione delle piattaforme. Un nuovo ecosistema di piattaforme non deve lasciare le infrastrutture sociali nelle mani delle aziende tecnologiche private. Deve includere spazi digitali di interazione e comunicazione dove il profitto non sia la logica dominante, dove le persone non siano soggette a sorveglianza e manipolazione, dove la comunità e la solidarietà possano svilupparsi libere dal controllo capitalistico, e dove le esigenze della società siano prioritarie rispetto agli interessi del capitale e degli azionisti. Come potrebbero essere queste piattaforme future? Per iniziare a rispondere a questo, dobbiamo considerare quattro elementi: proprietà, struttura, funzione e governance. ..." https://www.cigionline.org/articles/rethinking-digital-platforms-post-covid… Traduzione Italiana: https://www.linuxtrent.it/nextcloud/index.php/s/jRCJ7mixQZ7aaGM rob

1 0

Audizione Senato DDL direttiva CC IT
by deborah de angelis May 19, 2020

May 19, 2020

Cari tutti, ho il piacere di informarvi che anche il Capitolo italiano di Creative Commons è stato audito lo scorso 14 maggio al Senato per esprimere il proprio parere sulla trasposizione della direttiva 2019/790/EU (c.d. Copyright. Per guardare l'intervento cliccate qui 👇 (minuto 3:42:58) http://webtv.senato.it/4621?video_evento=80701 Per leggere la relazione completa cliccate qui 👇: https://creativecommons.it/chapterIT/index.php/1124/ Un caro saluto Deborah DDA Studio Legale ------------------------------------------------ Avv. Deborah De Angelis 00195 Roma (RM), Via Giuseppe Ferrari, 2 Tel. +39 06 59871248 www.ddastudiolegale.it info(a)ddastudiolegale.it skype: deb.dda Il presente messaggio, corredato dei relativi allegati contiene informazioni da considerarsi strettamente riservate, ed è destinato esclusivamente al destinatario sopra indicato. Chiunque ricevesse questo messaggio per errore o comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, copiarlo, divulgarlo, distribuirlo a persone diverse dal destinatario è severamente proibito e, nel caso, è pregato di rinviarlo immediatamente al mittente distruggendo l'originale. This message, together with its annexes, contains information to be deemed strictly confidential and is destined only to the addressee(s) identified above. If anyone received this message by mistake or reads it without entitlement is forewarned that keeping, copying, disseminating or distributing this message to persons other than the addressee(s) is strictly forbidden and is asked to transmit it immediately to the sender and to erase the original message received.

1 0