[T10] Tape Stream Mirroring - Encryption Security

Dennis Appleyard dennis.appleyard at oracle.com
Wed Feb 17 15:21:55 PST 2016


<< My inline responses to Kevin's comments >>

Kevin D Butt wrote:
> *<<comments inline below>>*
>
> Kevin D. Butt
> SCSI Architect, Tape Firmware, CAMSS
> T10 Standards
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
>
> From:        Dennis Appleyard <dennis.appleyard at oracle.com>
> To:        t10 at t10.org
> Date:        02/16/2016 11:54
> Subject:        [T10] Tape Stream Mirroring - Encryption Security
> Sent by:        t10-bounces at t10.org
> ------------------------------------------------------------------------
>
>
>
> All,
> I have posted 16-019r1 (SSC-5, ADC-4 : Tape Stream Mirroring ladder 
> diagrams) with three additional sequence diagrams showing how an 
> application client can ensure the security of logical block encryption 
> parameters in the tape stream mirroring destination device when 
> encryption parameters are under the exclusive control of the 
> sequential-access device server.
>
> Encryption may also be controlled by an automation/drive interface 
> (see ADC) or a vendor specific management interface.
>
> These new functions use the encryption mode locking and key instance 
> counters described in SSC-5.
>
> I am proposing the following additional functions:
>
> SSC - set TSM lock encryption
> SSC - set TSM reference key instance counter
> SSC - check TSM lock encryption
> SSC - check TSM reference key instance counter
>
> The state of lock encryption and the reference key instance counter 
> are not allowed to be changed while a tape volume is mounted.
> *<<kdbutt: I assume you mean TSM lock encryption and TSM reference key 
> instance counter? >> <<  Yes >> *
>
> Setting lock encryption instructs the copy manager to set the LOCK bit 
> in the SPOUT command Set Data Encryption page when setting the the 
> scope to PUBLIC in the copy destination.
>
> The application client sets up the encryption parameters in the copy 
> source and copy destination. The application client reads the key 
> instance counter from the copy destination. This becomes the reference 
> key instance counter. *<<kdbutt: Is there are potential for the copy 
> destination to be changed unnoticed here, between the set and the read 
> of the instance counter?>>* *<<  Yes, that is why the application 
> client does a SPIN command to read the Data Encryption Status page and 
> checks that the I_T_NEXUS SCOPE field is still set to ALL I_T_NEXUS. 
> If some other application had changed the encryption parameters on the 
> copy destination using a SCOPE of ALL I_T_NEXUS then the I_T_NEXUS 
> SCOPE reported by the SPIN command would have changed to PUBLIC. >> *  
> The application client passes the reference key instance counter and 
> lock encryption to the copy source (copy manager). The tape is 
> mounted.  After the tape is mounted the reference key instance counter 
> and state of lock encryption can not be changed. The application 
> client then checks that the reference key instance counter and lock 
> encryption were not changed just before the tape was mounted. The copy 
> manager then reads the key instance counter from the copy destination 
> and checks that it equals the reference key instance counter. The copy 
> manger then uses a SPOUT command to set a SCOPE of PUBLIC and LOCK bit 
> set to one *<< in the copy desetination >>*. If an unauthorized 
> application client changes the public encryption parameters being used 
> by the copy destination then write commands will fail because the key 
> instance counter has changed. *<<kdbutt: By unauthorized, I think you 
> mean any ac other than the copy manager. There is no intent to bring 
> in "Authorization" as defined in the security world?>> << **That is 
> correct** >>*
>
> The diagrams show how a change of the encryption parameters in the TSM 
> copy destination by an unauthorized application client is detected by 
> the application client, detected by the copy manager or causes write 
> errors on the destination device.
>
> The new diagrams are;
> Application Control of Tape Stream Mirroring (TSM) with Encryption - 
> Rogue SPOUT Before TSM
> Application Control of Tape Stream Mirroring (TSM) with Encryption - 
> Rogue SPOUT Start TSM
> Application Control of Tape Stream Mirroring (TSM) with Encryption - 
> Rogue SPOUT During TSM
>
> I plan to discuss these diagrams on the Telecon Thursday February 18   
> 9:00a - 11:00a PST.
>
> Thanks,
> Dennis Appleyard
> Oracle
>
>
>
>
>  _______________________________________________
> T10 mailing list
> T10 at t10.org
> http://www.t10.org/mailman/listinfo/t10
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20160217/27f5741b/attachment.html>


More information about the T10 mailing list