Intel vient de publier un PCN (Product Change Notification) concernant les tout fraichement lancés processeurs Skylake. Ce PCN indique l'arrivée de nouveaux ...
Lire la suite ...

Je vois que j ai bien fait de mettre mon upgrade en attente

A chaque nouvelle archi c'est le même topo.
Comme le commentaire au dessus, vaut mieux être patient et éviter de sauter sur la première révision sortie afin d'éviter d'essuyer les plâtres.

  Mouais... perso je ne suis pas si pressé que ça

C'est moi ou cette news n'est pas rédigée de façon claire ?
J'ai du lire l'actualité dans son intégralité pour réaliser que les premiers lots de Skylake n'ont pas de SGX alors que ceux qui devraient bientôt être mis sur le marché l'auront.
Je trouve que cette phrase induit en erreur : "Ce PCN indique l'arrivée de nouveaux S-Spec pour tous les processeurs Skylake disponibles actuellement sur le marché."

Je vous trouve bien positif concernant les livraisons de 6700K, quelques dizaines de 6700K à une poignée de revendeur pour la France, ce n'est Byzance...
Il doit y avoir des centaines des revendeurs en France qui pleurent toujours pour avoir leur premier !

Disons qu'ils pleurent parce qu'ils ne peuvent pas profiter aussi de la pseudo pénurie pour se faire les 50 € de marge supplémentaire que se font les autres

 
Moi, ça me parait clair, le 1er paragraphe (4e et 5e ligne) se termine par : "[...]que l'on pensait déjà présente dans les modèles actuels. Ce n'était cependant pas le cas."

"Ce n'était cependant pas le cas."
Ah oui, cette phrase vient d'être rajoutée, c'est en effet plus clair comme ça

Question : quelle a été la communication d'Intel sur le sujet ? Le stepping sans SGX était-il marqué comme disposant de la fonction ?

J'ai rajouté pour clarifier et précisé ce qu'était un S-Spec aussi
 

La communication d'Intel est le PCN
 
La présence ou non de SGX n'était pas indiquée sur ARK (cf archive.org : http://web.archive.org/web/2015090 [...] o-4_20-GHz en septembre) et elle ne l'est toujours pas ( http://ark.intel.com/products/8819 [...] o-4_20-GHz ). On voit juste SSE 4.1/4.2/AVX 2.0 dans le jeu d'instruction, et support de TXT (qui est, en tirant un peu, l’ancêtre de SGX). Les datasheet parlent bien de SGX mais ne précisent pas les modèles compatibles, elles évoquent simplement les nouveautés de la "famille" sans rentrer dans le détail des modèles.  
 
Intel est très doué en "communication"

La situation était pire aux US vu que même les gros e-tailers n'en ont pas eu ou qu'une poignée (alors qu'en Europe ils ont été globalement mieux servis ou soignés, peut être au dépend des revendeurs locaux d'ailleurs). Mais je crois que l'on a indiqué dans l'article que la disponibilité est globalement anormale pour Intel.

Le 32nm n'a pas réussi à AMD, le 14 nm ne semble pas réussir à Intel... Y'a toujours un node maudit

je sens les sécurités pourries qui vont ce greffer la dessus... peut etre qu'il vaut mieux prendre le modèle sans en fait...

C'est étrange cette histoire de dispo, pour avoir pas mal suivi la vente des 6700K je ne suis jamais tombé sur un jour ou je n'en trouvais pas de dispos et à prix classique parmi les revendeurs en ligne.

Je pense que du malware pourra se servir de ce truc afin de garder confidentiel son fonctionnement

Toi aussi ça t'as directement pensé à l'agence dont le sigle est composé de 3 lettres?
 
Je comprends que cette techno a une certaine utilité côté application serveur.
Néanmoins, cette techno mise dans de mauvaises mains, semble quand même un peu WTF.

J'ai lu (en diagonale) la spec de SGX ( https://software.intel.com/sites/de [...] 98-002.pdf ), je reste perplexe devant ce a quoi ça sert.
 
Clairement Intel met en avant l'aspect secret/sécurité, mais plus je vois l'implémentation et les limitations, plus le problème est à l'envers, c'est tout sauf la sécurité de l'utilisateur final qui est prise en compte.  
 
Trois posts de blogs chez Intel pour démystifier la techno mais qui résument assez bien :
https://software.intel.com/en-us/bl [...] -intel-sgx
https://software.intel.com/en-us/bl [...] ies-part-2
https://software.intel.com/en-us/bl [...] ies-part-3
 
Les objectifs posés dans le premier post sont assez clairs :  
 

 
J'ai juste pris les trois premiers parce que ce sont les plus importants. Clairement y'a une constante dans la spec, l'idée est de protéger code et données, et donc de protéger avant tout les développeurs.  
 
L'idée de base de l'implémentation est de faire tourner du code non analysable par un débogueur ou toute autre méthode (il y'a un mode spécial développeur qui permet d'attacher un débogueur a l'enclave quand on développe son code, avant la signature pour la version finale non deboguable), qu'on soit en ring-3, ring-0, virtualisé, SMM, et tout faire pour protéger contre les attaques hard d'une personne qui aurait un accès physique à la machine.  
 
Cela reste une "sécurité par obscurité" que j'ai du mal a concevoir comme bénéfique pour l'utilisateur. Il y a une différence entre vouloir garder des données secretes (une clef de cryptage) et l'isoler, et garder secret le code qui l'utilise. Il peut y avoir un intérêt a valider le code qui l'utilise, a s'assurer qu'il n'est pas modifiable, mais la spec va au delà en le gardant secret y compris de l'utilisateur.
 
Qui plus est en matière d'implémentation pratique on est limité a interagir dans son code et ses pages mémoires, l'isolation est forte donc on peut oublier l'idée d'utiliser SGX pour "cloisonner" des plugins ou des applications, ca n'a pas été conçu pour ça.  Tout va toujours dans le même sens dans la spec, un utilisateur connecté a une machine, y compris avec un niveau de privilège maximal, reste "l'ennemi". Alors que c'est (on l'imagine), sa machine. Car si un utilisateur malveillant est connecté en tant que root, par définition, la bataille est perdue pour l'utilisateur original et aucune mesure de protection n'y fera rien.  
 
J'ai également énormément de mal avec la Device Key unique incluse dans chaque Skylake. Techniquement l'implémentation semble moins ridicule que le "processor id" des années 90 (rappel : https://www.schneier.com/essays/arc [...] or_id.html ), mais ca reste un identifiant unique. A première vue la key n'est accessible que dans le mode enclave, et pas directement (on obtient une clef dérivée pour chaque app enclave, mais elle permet toujours d'identifier de manière unique l'utilisateur). Reste que c'est un identifiant unique qui est réintroduit, et a ma connaissance il n'y en avait pas jusqu'ici dans les CPU Intel pré-Skylake. On ne sait pas de plus comment il est généré.
 
En pratique on n'a aucun contrôle en tant qu'utilisateur : du moment ou l'on accepte qu'un programme enclave tourne, il pourra accéder a la clef unique. On peut se poser la question de l'intérêt pour l'utilisateur de devoir vérifier l'id de son processeur, l'idée mise en avant est de prouver a distance a un serveur que l'on est qui on est.
 
Donc en pratique a quoi sert SGX ? Intel a sous entendu que cela pouvait servir pour le Protected Video Audio Path, en gros les DRM dans les drivers vidéos pour empêcher l'accès aux buffers.
 
L'idée d'imposer des blobs cryptés SGX pour autoriser la lecture de contenu vidéos "next gen", que ce soit en streaming via des plugins HTML5 vidéo qui nécessiteraient un blob SGX, ou pour les lecteurs logiciels Blu-Ray 4K semble une utilisation assez probable. On verra surement des utilisations entreprises, par exemple pour tout ce qui est documents "sécurisés" et possiblement des DRM d'application/jeux, la spec est clairement faite pour ca : identifier de manière unique une machine et la valider avec un serveur distant.  
 
Au delà, la spec ne résoudra rien des problèmes de sécurité actuels et ouvre la porte a l'installation de malwares, d'enclaves mal écrites et exploitables, de tracking persistant, de drivers cryptés, et de totale obscurité. Intel donne en point 3 l'idée que l'utilisateur doit garder le contrôle en pouvant installer et désinstaller ses applications (l'explication longue du point 3, dans le deuxième post de blog, répond totalement à côté de ces préoccupations en passant). L'idée de dire qu'on peut le désactiver dans le BIOS (quand on y a accès), ou que l'OS pourrait avertir avant le lancement d'un blob sécurisé (après UAC, j'ai peu d'espoir de la forme que cela pourrait prendre) n'est pas très rassurante. Si après demain les drivers vidéo (ou réseau, ou autre) necessitent SGX pour tourner, l'utilisateur n'aura pas vraiment le choix et ouvre la porte en grand aux enclaves malveillantes. Les anti-virus/malware n'auront aucun moyen de vérifier si d'éventuels blobs enclaves tournent, ce qu'ils font, s'ils sont malveillants ou pas.  
 
Pour l'instant évidemment, cela ne concerne que Skylake, et Intel, rien ne dit qu'AMD suivra (mais TPM, l'ancètre de SGX au niveau plateforme, est aussi dispo chez AMD), mais la porte ouverte par Intel parait extrêmement dangereuse pour les utilisateurs et l'avenir du PC, pour un gain extrêmement limité.

Un exemple d'utilisation pour les particuliers : canalsat pourrait créer un logiciel pour décoder son bouquet de chaines sur un pc équipé d'une carte satellite. Sans avoir besoin d'un lecteur de carte, la sécurisation du soft et l'identifiant unique suffisent.

Combien de temps avant qu'on apprenne que ces enclaves sont transparentes pour la NSA?

Pas convaincu que ca soit un bon exemple, pour le coup les abonnés C+/CSat peuvent déjà streamer les chaines avec une identification par mot de passe
 
Et tant bien même, en quoi retirer la carte pour la remplacer par un identifiant qui devra en permanence etre revalidé (impossible d'auth en permanence sur le token si le device est volé, etc) est un progrès qui justifie les risques de sécurité encourus ?

Je vois un gros avantage pour les jeux en ligne: la validation jusque là réalisée par le serveur peut être partiellement déléguée au terminal du joueur. Ca veut dire un peu moins de latence.

Oui, c'est juste un exemple, je ne pense pas que ça réponde à un besoin.
Je voulais surtout montrer que sur le plan technique, ça permet de remplacer un décodeur C+/Csat par un PC. Il me semble que la clé de validation des abonnements est transmise par le sat toutes les 20 min. ça donne un système sécurisé sans accéder au net. Un terminal volé est désactivé par le signal sat (il ne reçoit plus sa clé).
Pour les services connectés au net, SGX me semble moins utile puisque la sécurité se trouve côté serveur.
De toute façon, on n'est pas près de voir des applications pour le particulier. Il faudrait déjà qu'une grosse partie du parc info soit équipé de cpu qui gère SGX.
 
Edit : Et pour l'inviolabilité du système, j'ai pensé moi aussi   que vu la multitude d'angles d'attaques possibles, on peut penser qu'il sera rapidement craqué.

Je doute qu'il y ait beaucoup d'infos publiques sur MediaGuard donc difficile d'en parler, mais au minimum la carte à puce contient un identifiant unique connu par Csat pour pouvoir les invalider.  
 
Or là si on remplace ca par SGX, on a un identifiant unique dans le CPU, mais inconnu de Csat sans au minimum un échange avec une voie de retour donc on ne bypassera pas totalement le besoin d'Internet
 

Oui ça pourrait (peut être, il y aura toujours des petits malins pour attaquer un autre niveau comme la couche réseau), mais ça impliquerait 100% des clients sous Skylake avec SGX actif ce qui est a court ou moyen terme probablement irréaliste.

Bonjour,
 
En fait, cette "fonctionnalité" ne serait-elle pas surtout utile pour les entreprises ?
Associée cela à des cartes PKI pour l'authentification par ex (voire même les supprimer) ?
 
Car Intel, pour ce cas précis, doit surement viser plus les entreprises que le particulier. Non ?
 
Le SGX est aussi présent dans les CPU Xeon ?

C'est juste    

Clairement, ça sera un vrai bonheur pour la NSA et les créateurs de malware qui ne veulent pas se faire détecter en mémoire par l'anti-virus.

Pas de SGX ? Mais que fait Silicon Graphics ?