Archive for the ‘multi-entité’ Category

Cosignature

Samedi, mai 9th, 2015

Une réflexion depuis quelques temps porte sur la cosignature (cf Les entités et le code / Redéfinition de puppetmaster). Et elle est toujours d’actualité. Le but est de permettre d’avoir une entité unique mais dont la clé privée soit répartie en plusieurs morceaux, chaque morceau sous la responsabilité d’une personne différente. On doit avoir plusieurs entités qui peuvent communément, et non individuellement, signer pour l’entité unique.

Le problème peux être résolu en ayant un mécanisme qui valide la signature de l’entité unique par la présence d’un nombre pré-définit de signatures d’entités pré-validées. On n’a plus dans ce cas une entité mais un groupe d’entités dont la cosignature est reconnue comme signature du groupe. Dans ce cas, la notion d’entité s’étend et ne sous-entend plus seulement un objet avec une clé cryptographique mais un objet qui constitue un groupe d’entités avec des règles de fonctionnement.

Jusqu’ici, je n’ai trouvé que des solutions matériels avec un seul bi-clé cryptographique conservé dans une puce et dont l’usage est contraint par l’authentification de plusieurs personnes physiques. Ce n’est pas satisfaisant puisque toutes les personnes doivent être présentes au même endroit au même moment pour activer la clé privée. Les solutions de cosignatures que j’ai trouvé se contentent de gérer de multiples signatures d’un document mais sans gérer cette notion de communauté.

Authentification et mot de passe

Samedi, février 14th, 2015

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
$_SESSION['nebule_publ_entite']
$_SESSION['nebule_priv_entite']
$_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Entités multiples

Mardi, décembre 23rd, 2014

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.