Sistemi di sicurezza

Questa sezione descrive lo sviluppo e la natura della API RPCSEC_GSS.

La sicurezza prima di RPCSEC_GSS

Uno dei primi sistemi di sicurezza supportati da RPC è stato AUTH_SYS (noto anche come AUTH_UNIX). AUTH_SYS utilizzava una credenziale in stile UNIX, basata sugli ID dell'utente e del gruppo, per identificare il mittente e il destinatario di un messaggio. AUTH_SYS è facile da implementare, ma è anche facile da aggirare poiché non utilizza una vera e propria autenticazione: il server non può infatti verificare che un client sia realmente chi dichiara di essere. Di conseguenza, è relativamente semplice creare una richiesta di rete fittizia in AUTH_SYS.

Successivamente ad AUTH_SYS è stato sviluppato un sistema di sicurezza più evoluto, AUTH_DES. AUTH_DES è basato su un'autenticazione a chiave pubblica: utilizza uno scambio di chiavi Diffie-Hellman per produrre una chiave comune tra la chiave privata del client e la chiave pubblica del server. La chiave comune viene quindi usata per cifrare una chiave di sessione DES, che viene decifrata dal server per l'apertura di una sessione.

AUTH_DES rappresenta un passo avanti rispetto ad AUTH_SYS, ma presenta alcune limitazioni che ne ostacolano l'utilizzo su larga scala. L'obiezione principale di molti utenti riguarda il fatto che la chiave appare sottodimensionata in rapporto agli standard di cifratura odierni.

È stato infine introdotto un altro sistema di sicurezza RPC. AUTH_KERB, basato su Kerberos V4, offre una sicurezza superiore rispetto a AUTH_DES o AUTH_SYS. Ma anche in questo caso non è garantita una protezione assoluta.

Per maggiori informazioni sui meccanismi di sicurezza, vedere la ONC+ Developer's Guide.

Integrità e riservatezza: la GSS-API

Per migliorare ulteriormente la sicurezza è stato aggiunto un nuovo livello di rete, la GSS-API (Generic Security Standard API), la quale, oltre all'autenticazione, che offre due servizi di sicurezza aggiuntivi:

• Integrità. Con il servizio di integrità, la GSS-API utilizza il meccanismo sottostante per autenticare i messaggi scambiati tra i programmi. Una serie di checksum cifrati determinano:

  • L'identità del mittente dei dati per il destinatario

  • L'identità del destinatario per il mittente (se è richiesta un'autenticazione reciproca)

  • L'autenticità dei dati trasmessi

• Riservatezza. Il servizio di riservatezza include il servizio di integrità. In più, i dati trasmessi vengono anche cifrati, in modo da essere protetti contro eventuali intercettazioni.

  A causa delle limitazioni all'esportazione vigenti negli Stati Uniti, è possibile che il servizio di riservatezza non sia disponibile per tutti gli utenti di SEAM.

Attualmente, la GSS-API non è esposta. Alcune funzioni della GSS-API, tuttavia, sono "visibili" attraverso le funzioni di RPCSEC_GSS -- possono cioè essere manipolate in modo "indiretto". Non è necessario che i programmatori gestiscano direttamente i loro valori.

La API RPCSEC_GSS

Il sistema di sicurezza RPCSEC_GSS permette alle applicazioni RPC ONC di usufruire delle funzioni della GSS-API. RPCSEC_GSS risiede "al di sopra" della GSS-API, come illustrato in questa figura:

Figura 8-1 Livelli di sicurezza della GSS-API e di RPCSEC_GSS

Usando la API per RPCSEC_GSS, le applicazioni RPC ONC possono specificare questi elementi:

meccanismo

Un paradigma di sicurezza. Ogni meccanismo di sicurezza offre un diverso tipo di protezione dei dati e uno o più livelli di protezione. In questo caso, si può trattare di qualunque meccanismo di sicurezza supportato dalla GSS-API (Kerberos V5, chiave pubblica RSA, ecc.).

servizio di sicurezza

Può essere il servizio di riservatezza o integrità (o nessuno). Il servizio predefinito è quello di integrità. Il servizio è indipendente dal meccanismo.

qualità della protezione (QOP)

La qualità della protezione specifica il tipo di algoritmo crittografico da utilizzare per implementare i servizi di riservatezza o di integrità. Ogni meccanismo di sicurezza può essere associato a uno o più QOP.

Le applicazioni possono ottenere un elenco dei QOP e dei meccanismi validi usando le funzioni fornite da RPCSEC_GSS. (Vedere "Altre funzioni".) Gli sviluppatori dovrebbero evitare di inserire QOP e meccanismi di hard-coding nelle applicazioni, in modo che non sia necessario modificarle per usare meccanismi e QOP nuovi o differenti.

Storicamente, i termini "sistema di sicurezza" e "sistema di autenticazione" sono stati usati con lo stesso significato. Con l'introduzione di RPCSEC_GSS, il termine "sistema di sicurezza" ha acquisito un senso differente. Un sistema può ora includere un servizio (integrità o riservatezza) in aggiunta all'autenticazione, anche se attualmente RPCSEC_GSS è l'unico ad offrire questa possibilità.

Con RPCSEC_GSS, le applicazioni RPC ONC possono stabilire un contesto di sicurezza con un sistema paritetico, scambiarsi dati e distruggere il contesto esattamente come con altri meccanismi. Una volta stabilito un contesto, l'applicazione può cambiare il QOP e il servizio per ogni unità di dati trasmessa.

Per maggiori informazioni su RPCSEC_GSS, inclusi i tipi di dati di RPCSEC_GSS, vedere la pagina man rpcsec_gss(3N).