Sécurité info - Page 24

Et si l'utilisateur souhaite utiliser son casque Bluetooth dans un avion ? Il ne doit pas pouvoir le faire ? Il peut le faire, mais devra éteindre son téléphone parce qu'il ne doit pas activer le GSM et le WiFi ? Il devrait désactiver les radios interdites manuellement et penser à tout réactiver lorsqu'il arrive ?

Pour moi :
- soit c'est interdit en avion, et tu ne dois pas pouvoir l'activer tant que le mode avion est actif
- soit c'est autorisé, et dans ce cas il n'y a pas de raison que le mode avion désactive cette radio

Je ne sais pas ce qu'il en est pour le Bluetooth.

J'ai donné l'exemple du Bluetooth parce que certaines compagnies l'autorisent et pas d'autres. Le WiFi est également autorisé pour certains vols.
Donc, il faudrait un mode avion qui sache ce qui est autorisé là où tu te trouves ? Comment proposerais-tu de réaliser ça ? Il me semble qu'il est plus simple d'avoir un mode avion qui désactive tout, mais qui laisse à l'utilisateur la possibilité d'activer ce qu'il veut parce qu'il en a éventuellement le droit.

Zerosquare (./692) :
Je ne sais pas ce qu'il en est pour le Bluetooth.

Le BT est désactivé en avion, et la localisation aussi, comme ça pas de recours au WIFI pour le gps "haute précision"

Les appareils Android permettent en général à l'utilisateur de les configurer pour activer le WiFi même en mode avion. Ce n'est pas totalement déraisonnable, il y a même des vols qui proposent le WiFi de nos jours.

Mais je ne sais pas comment ça interagit avec cette histoire de réseau activé même quand c'est censé être désactivé.

Il y a 7 ans, il y avait déjà des avions avec Wifi.

https://www.bleepingcomputer.com/news/security/blueborne-vulnerabilities-impact-over-5-billion-bluetooth-enabled-devices/

youpiiii

YeaY

\o/

\o\

Oo=======@ ~~~~~~~ \o/


Hem non pardon, je m'égare !

:D

Le document qui décortique les failles est intéressant à lire, et dit clairement que le côté usine-à-gaz de la spéc Bluetooth est en partie responsable de ce genre de bugs :

http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf :
Bluetooth is complicated. Too complicated. Too many specific applications are defined in the stack layer, with endless replication of facilities and features. These over-complications are a direct result of the immense work, and over-engineering that was put into creating the Bluetooth specification. Just to illustrate this point: while the WiFi specification (802.11) is only 450 pages long, the Bluetooth specification reaches 2822 pages.

Bluetooth’s complexity kept researchers from auditing its implementations at the same level of scrutiny that other highly exposed protocols, and outwards-facing interfaces have been treated with. The result of the lack of review is a large number of vulnerabilities, such as those which we are disclosing here. The complications in the specifications translate into multiple pitfall junctions in the various implementations of the Bluetooth standard.

An example of the unnecessary complexity of Bluetooth is fragmentation, a common concept in many protocols, and a soft spot in every implementation. The Bluetooth specification has no less than 4 different fragmentation layers implemented throughout the stack (...) the faulty design of SDP’s fragmentation mechanism makes it a terribly hard mechanism to implement without bugs. Even when specific validations are put in place (as in Android’s implementation) - eliminating all bugs that can be a result of convoluted state confusions is almost an impossible mission.

Je pense que le jour où quelqu'un aura le courage de passer au peigne fin les spécs USB, ça va être rigolo aussi. Et encore plus maintenant que WebUSB existe, d'ailleurs.

la y'a des merdes bien connues oui, genre les zero length packets etc.

Sinon, un truc étonnant vu à l'instant : il semble qu'il existe une norme de certification pour la sécurité des objets connectés, faite par un institut respecté :
https://iot.stackexchange.com/questions/269/is-there-a-certificate-to-indicate-the-security-level-of-iot-devices

Peut-être une petite lueur d'espoir si ça devient un jour obligatoire pour pouvoir commercialiser un machin IoT ? (bah quoi, on peut rêver ^^)

3000 pages de specs ?! Oo

Il faut bien ça

Sinon l'explication est la même que d'habitude : ce sont des machins créés par des gros comités où chacun met son grain de sel et tire la couverture à lui. Le résultat est inutilement compliqué, ça génère plein de paperasse indigeste et c'est pénible à implémenter.

avec peut-être la NSA qui fait exprès de compliquer les choses pour rajouter des failles

^^

je viens de voir que linusque a corrigé un CVE et que mint vient de le récupérer ^^

toujours plus groin

https://blog.acolyer.org/2017/09/21/clkscrew-exposing-the-perils-of-security-oblivious-energy-management/

Cette vulnérabilité n'est pas vraiment un risque de sécurité, elle sert avant tout à attaquer le système d'informatique déloyale appelé TrustZone.

Oui oui tu prouve encore une fois que tu n‘as rien compris aux problèmes (oui au pluriel)

Tu pourrais au moins expliquer pourquoi stp ?

Expliquer à Kevin? Pas sur que ca fait à grand chose.


Mais bon.

1- TrustZone provoque des peurs irrationnelles chez certains a l’image du TPM à l’époque.
TPM est la, utilisé et... le monde ne c’est pas ecroulé.

TrustZone sert à avoir une chaîne des confiance pour l’execution de choses sensibles et est (malheureusement) un rempart contre les malwares et autres potentiels hack. Sachant que 99.9999999% des téléphones et autres appareils mobiles sont dans les mains de Mr Toutlemonde et que cette personne ne pige pas un brin d’en tout ça il faut éviter au maximum que son smartbidule serve à des fins malveillantes à son insu.
TrustZone sert aussi à sécurisé la crypto comme celle pour tes donnée perso.


La faille elle n’est pas spécifique à TrustZone, mais au chip dans son ensemble. Pourquoi TrustZone comme exemple ? Parce que c’est sensé être assez bien sécurisé et, si pas impossible, très difficile à attaquer.

C’est effectivement une faille majeure si c’est aussi simple à utiliser qu’ils le disent et qui va être difficile à corriger/protéger..

Merci pour l'explication.

Ouais enfin, il existe des moyens de sécurisation des flux et de certification des applications robustes qui ne nécessitent pas de technologies telles que TrustZone.
En plus, on sait depuis déjà longtemps qu'un mécanisme de sécurité en dur au niveau du matériel et/ou du firmware est, à terme, une faille potentielle de sécurité : le jour où il est cassé, ce sont tous les matériels touchés qui sont perméables, sans possibilité de mise à jour. C'est déjà arrivé chez Intel, et la seule solution qu'ils ont trouvé pour régler le problème a été (à condition que l'utilisateur soit au courant et fasse les mises à jour en question, ce qui n'est pas trivial) de désactiver ces technologies.

trustzone et tpm n'on RIEN RIEN RIEN a voir

laissez kevin s'étaler dans ses conneries.

mode intéressant:

tpm = chip qui fait les calculs RSA en dehors du PC, en gros une smartcard soudée, c'est safe, ca marche, ca faisait peur aux libristes avant que microsoft donne un grub signé pour lancer ce qu'on veut (puis c'est très souvent désactivable).

Trustzone: mode supplémentaire du CPU ARM avec des registres a part et des privilèges pour accéder a des zones mémoires de manière exclusive. on passe en mode trustzone avec un trap special, c'est un genre de kernel++ sécurisé qui permet de faire des calculs de manière relativement plus sécurisés que le RSA512 des ti 68k (vu que les autres processus ne peuvent pas lire ces zones mémoires). (note: il y a un mode user et un mode superviseur également en trustzone).

sauf que tu peux glitcher le CPU en jouant sur la tension et la fréquence, et que forcément ca glitche le code qui s'exécute en mode trustzone AUSSI. et c'est cassé par design.

Et de plus, contrairement au Management Engine de Intel qui tourne en parallèle du CPU sur tous les northbridges de la planète (mais ca kevin n'en a pas peur), TrustZone ne s'exécute pas en parallèle mais a la demande.

ceci dit comme Nil le signale le vrai code sécurisé est censé savoir résister aux attaques side channel et injection de fautes, si ce n'est pas le cas c'est que des pignoufs ont codé avec deux cerveaux gauches.

Je n'ai pas souvenir d'avoir dit que TrustZone et TPM etait la meme chose. Je n'ai comparé que sur les cris d'orfraie de certains a propos de l'un et de l'autre.

Je suis fondamentalement pas d'accord avec Nil, pour faire de la crypto correctement pour le commun des mortels on a besoin d'enclaves comme l'est TPM ou TrustZone. TZ ne permet pas le stockage des clefs en direct, mais permet au moins de protéger le cryptage et hashage de potentiel malwares, empecher l'execution de code douteux etc...

Je n'ai pas eu d'autre intention que de faire taire les cris d'orfraie de certains

(bref, je sais que tu sais)