Browse Prior Art Database

Protection of confidentiality in data analysis equipment Disclosure Number: IPCOM000127259D
Original Publication Date: 2005-Aug-19
Included in the Prior Art Database: 2005-Aug-19
Document File: 2 page(s) / 61K

Publishing Venue



Protection of Confidentiality in Data Analysis Equipment

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

Page 1 of 2

Protection of confidentiality in data analysis equipment

Engineers use logic or protocol analysers to debug computer systems and network. If this debug activity occurs at a customer location, it is possible for the analysers to capture sensitive or confidential customer data. This may be undesirable or even forbidden according to the nature of the data. On the other hand, if the engineers are not allowed to examine the data, this may impede the debug of the problem. This note proposes an encoding system that scrambles the customer data, rendering it unreadable to humans, but still leaves it in a form that can be used for useful debug work.

  A logic or protocol analyser is designed to capture data from a computer system or network and display this information in a readable and meaningful way. Normally the displayed information will be broken down into various frames or fields. These will include things like type of frame, address id, source id, crc and so on. Data fields or frames will also be displayed. This note describes a method of encoding these data fields in a way that prevents the person using the analyser from reading the data but still allows them to use this data for useful debug activity.

  The analyser is programmed to process frames or fields that contain customer data. Before displaying this data, the data is transformed by applying a suitable encryption function. The characteristics of this function should be: it should ensure that the customer data cannot be read by the engineer using



the analyser, even when that engineer has cryptographic skills (ie has some knowledge of how to break encryption skills) it should nevertheless allow the engineer to determine if data has been

corrupted within a given data frame (eg if the engineer is examining a write operation followed by a read operation for the same data location in a storage subsystem, the engineer must be able to verify that the data written and the data read back are identical.

  Requirement (1) means that a simple encryption scheme (eg a byte substitution scheme) would not be suitable, as this would be too easy to break. Eg if the byte sequence 01 23 45 67 is always transformed into AA BB CC DD then this would make it easy to check that the byte sequence had not been corrupted but simple frequency analysis would be enough to break the code.

  A more complex encryption schemes would meet requirement (1) but would make it more difficult to meet requirement (2). Eg if the byte sequence 01 23 45 67 is transformed, when displayed into AA BB CC DD the first time it appears and 99 88 77 66 the second time it appears, how can the engineer confirm that these two apparently different encoded sequences are actually the same?

  The answer is to build an "assistant" into the logic analyser function that can answer these type of questions. The logic analyser can then encrypt the customer data with a strong encryption scheme, and then the "assistant" can decrypt the data if nec...