Browse Prior Art Database

A Method for Secure Key Synchronization of Multiple Processors across Multiple Power Outages

IP.com Disclosure Number: IPCOM000240802D
Publication Date: 2015-Mar-04
Document File: 4 page(s) / 148K

Publishing Venue

The IP.com Prior Art Database

Related People

Chet Helms; Richard A. Rekoske: INVENTOR

Abstract

This invention provides a dependable mechanism to change keys on all processors of the meter in one action, regardless of continuous power to the device.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 61% of the total text.

Elster Solutions, LLC

208 S. Rogers Lane, Raleigh, NC 27610

Inventors:  Chet W. Helms

Richard A. Rekoske

E20140180 -- A Method for Secure Key Synchronization of Multiple Processors across Multiple Power Outages.

Background:

This invention provides a dependable mechanism to change keys on all processors of the meter in one action, regardless of continuous power to the device.

Description:

Keys are often used in a processor for the encryption of stored data and communication payloads. Given a local system with multiple processors which all communicate to a central processor, keys will be changed and synchronized by the central processor.

In a traditional setup, each processor stores a local set of keys in non-volatile storage. Commands are sent to each processor encrypted with one of the local keys to change one or more of the keys. If the command is valid, the key is changed and the response is encrypted with the same key as the request. This would typically require an external system to change the keys on each processor individually, in a specific order to keep keys synchronized.

In this invention, all key changes are executed on the central processor. The following is a typical sequence of events :

1)      External system sends an encrypted valid key change request to the central processor

2)      The central processor, while temporarily suspending access to keys by higher priority threads, performs the following:

a.       Saves a copy of the local keys as old keys for use in the key synchronization

b.      Changes the local keys to the new keys in the request

3)      The central processor sends an encrypted response to the request using the original encryption key of the request

4)      The central processor starts changing the keys of the other processors, using the old keys until they accept the new keys

The state of the keys module in the central processor contains the following states:

  • IDLE – No key change or synchronization is in progress
  • CHANGING_LOCAL_KEYS – Changing the local key
  • KEY_SYNCHRONIZATION – Keys are synchronizing

The keys module state is stored in non-volatile memory. Information on which processors and keys have been changed are stored a table in non-volatile memory.  The following demonstrates the table form assuming four keys and three auxiliary processors: 

Pending Changes Table

Key ID

Processor ID

Is Key Synch Pending

0

0

True/False

0

1

True/False

0

2

True/False

1

0

True/False

1

1

True/False

1

2

True/False

2

0

True/False

2

1

True/False

2

2

True/False

3

0

True/False

3

1

True/False

3

2

True/False

The key synchronization process in the central processor functions according to the following flow chart:

 For each key changed on the central processor, a change operation needs to be performed on every auxiliary processor. The central processor sets the Is Key Synch Pending Flag for each (Key ID, Processor ID) pair that includes a modified key. The key synchronization process loops through each (Key ID, Processor ID) pair of the Pending Changes Tabl...