Browse Prior Art Database

Method for Reducing Theft of Computing Equipment

IP.com Disclosure Number: IPCOM000015339D
Original Publication Date: 2002-May-08
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

Disclosed is a method for reducing theft of computing equipment and securing the data stored on it. Equipment theft is a serious problem spanning the spectrum from servers that disappear to laptop computers. This disclosure renders stolen IT or wireless equipment worthless to the thief and it's data inaccessible. This invention will only work for systems that have network connectivity at least part of the time and would be applicable to workstations, servers, wireless devices, and potentially items with embedded processors. A piece of hardware utilizing the idea disclosed herein would contain the capability to discover and retain an identity from an authorized system on a network. In essence, when first connected to a LAN, the device 'imprints' on that LAN and refuses to operate unless it is on it's home LAN. A new piece of hardware would be shipped 'blank', that is, containing no identity. When it is hooked up to the network for the first time, the hardware in the box would broadcast a "who am I" message. A computer system on the LAN that is an authorized validator would establish a secure session with the box and give it validation information (possibly an encryption key) and an identity which the box would remember. A possible implementation would be a challenge/response sequence where the hardware in a box (device being validated) has remembered a public encryption key provided by a validator when the box first 'imprinted'. The authorized validator(s) would know the corresponding private key. The box would generate some psuedo-random data and send it to the validator. The validator would encrypt it with the private key and return it. The box then uses the remembered public key to decrypt the returned data and see if it matches the original data it sent to the validator. If so, it has a successful validation. If not, it takes whatever steps it has been programmed to render itself useless to the present user. Note that in this scenario, the validation does not have to be against the same validator but will succeed against any validator that knows the proper keys. A business may use one validation key for the enterprise which would allow equipment to be moved freely between offices, etc. Alternatively, the box could be set up with a hierarchy of public keys all of which would have to fail before the validation was considered to have failed. Other validation schemes are possible. Critical or high value parts in the system such as disk drives could also validate independently of the system unit allowing them to refuse to function if they have been moved to a machine which cannot validate against the same enterprise. This would render inaccessible the data on a bank of hot swap SCSI disks that went out the door in someone's briefcase. Again, such parts would ship 'blank' with no identity and would gain an identity when the system first validates. A possible implementation would be for the identity returned by the validator on the initial connection to the network to be in two parts. The validator uses part 'A' of the identity as a key and part 'B' as data and inserts them into a data store. The system stores part 'A' of the returned identity in nonvolatile memory but keeps part 'B' only in volatile memory so it doesn't survive a power cycle. When a 'blank' part in the system initializes (any part containing a processor, memory, and a nonvolatile store such as a disk drive), it requests the part 'B' of the identity from the system board and saves it in nonvolatile memory. On subsequent validation sequences, the box ships a fixed length of random data to the validator as above but appends it's part 'A' to the request. The validator looks up the part 'B', appends it to the random data, encrypts the whole thing, and returns it to the box. The box decrypts the frame and saves part 'B' in volatile memory. When a disk drive (for example) comes up it realizes it has an identity and asks the box (the system board) 'who are you?'. The system board replies with part 'B' of the identity. If it matches what the drive has previously stored, the disk drive operates. Else it does not operate. Again, this has to be implemented in the device hardware where it can't be easily replaced or tampered with.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 2

Method for Reducing Theft of Computing Equipment

Disclosed is a method for reducing theft of computing equipment and securing the data stored on it. Equipment theft is a serious problem spanning the spectrum from servers that disappear to laptop computers. This disclosure renders stolen IT or wireless equipment worthless to the thief and it's data inaccessible. This invention will only work for systems that have network connectivity at least part of the time and would be applicable to workstations, servers, wireless devices, and potentially items with embedded processors.

A piece of hardware utilizing the idea disclosed herein would contain the capability to discover and retain an identity from an authorized system on a network. In essence, when first connected to a LAN, the device 'imprints' on that LAN and refuses to operate unless it is on it's home LAN. A new piece of hardware would be shipped 'blank', that is, containing no identity. When it is hooked up to the network for the first time, the hardware in the box would broadcast a "who am I" message. A computer system on the LAN that is an authorized validator would establish a secure session with the box and give it validation information (possibly an encryption key) and an identity which the box would remember.

A possible implementation would be a challenge/response sequence where the hardware in a box (device being validated) has remembered a public encryption key provided by a validator when the box first 'imprinted'. The authorized validator(s) would know the corresponding private key. The box would generate some psuedo-random data and send it to the validator. The validator would encrypt it with the private key and return it. The box then uses the remembered public key to decrypt the returned data and see if it matches the original data it sent to the validator. If so, it has a successful validation. If not, it takes whatever steps it has been programmed to render itself useless to the present user. Note that in this scenario, the validation does not have to be against the same validator but will succeed against any validator that knows the proper keys. A business may use one validation key for the enterprise which would allow equipment to be moved freely between offices, etc. Alternatively, the box could be set up with a hierarchy of public keys all of which would have to fail before the validation was considered to have failed. Other validation schemes are possible.

Critical or high value parts in the system such as disk drives could also validate independently of the system unit allowing them to refuse to function if they have been moved to a machine which cannot validate against the same enterprise. This would render inaccessible the data on a bank of hot swap SCSI disks that went out the door in someone's briefcase. Again, such parts would ship 'blank' with no identity and would gain an identity when the system first validates. A possible implementation would be for...