WO2013156663A1

WO2013156663A1 - Password provision for power system device

Info

Publication number: WO2013156663A1
Application number: PCT/FI2012/050383
Authority: WO
Inventors: Janne Starck; Juha EKHOLM; Jukka RANKAVIITA
Original assignee: Abb Technology Ag
Priority date: 2012-04-18
Filing date: 2012-04-18
Publication date: 2013-10-24

Abstract

An access verification method for a power system device, comprising steps of receiving a predetermined user input from a user of the device (1-2), providing a request key upon the received predetermined user input (1-4), providing the request key for the user of the device (1 -6), receiving a verification key from the user of the device (1-14), evaluating if the verification key is an acceptable response to the request key that was provided for the user (1-16), and providing access for the user to the device if the evaluation indicates that the received verification key was acceptable (1-18).

Description

PASSWORD PROVISION FOR POWER SYSTEM DEVICE

FIELD

The present invention relates to provision of a password for a power system device. Especially, the invention relates to a situation where an access password to the device is no longer available.

BACKGROUND

Occasionally, a user, such as an administrator, of a power system device, loses or is otherwise unavailable to use an access password to the device.

Currently, in such as situation, the device is disengaged from the network and sent back to a factory for a password reset. This is a very time- consuming and laborious process. Alternatively, the device may be provided with a hard-coded backdoor. However, access of persons that no longer should have access to the device cannot thereby be prevented.

An improvement to the current way of operation in the case of an unavailable password is required.

SUMMARY

An object of the present invention is to provide a method and device so as to alleviate the above disadvantages. The object of the invention is achieved by a method and a device, which are defined in the independent claims. Some embodiments are disclosed in the dependent claims.

In an embodiment, the device is a protective relay or some other protection and/or automation device operating in a power system, also called as an IED (Intelligent Electronic Device).

The device comprises a user interface. The user interface may comprise a local human machine interface (LHMI) and/or a data communication connection. The LHMI may comprise one or more elements of a group including a keyboard, a mouse, a joystick, a display, a microphone and a loudspeaker. The data communication connection may include a wireless connec- tion and/or a wired connection. The data communication connection may allow the use of the device from the immediate proximity of the device and/or from a remote location. The data communication connection may utilize a private data communication network and/or a public network, such as the Internet.

A user may enter a predetermined input on the user interface. If the user uses the LHMI of the device, the predetermined input can be a certain key combination, for instance. If the user uses the device remotely, that is not via the LHMI, the predetermined input may refer to certain data received via a communication link. Entering of the predetermined input bypasses a normal request of a user identity and/or password. The device comprises a first algorithm for generating a request key (key A), which is a response to a user giving the predetermined input for initiating the procedure for obtaining an access right to the device.

In an embodiment, the provided request key is unique each time it is requested. The uniqueness of the request key may be arranged by including a dynamic step counter to the key, that is, a running number telling how many times the password request has been applied on the device is included to key A. Key A may include also other dynamic information, such as the date of the request, for instance.

The device provides the request for the user. The code may be provided, for instance, on the display of the device, by sound/voice, or it may be transmitted to the user's device, such as a laptop or a mobile phone via a communication link.

In addition to key A, the device may provide the user with some fur- ther information on the user interface, such as a device identity and/or a media access control (MAC) code of the device.

The user uses the obtained request key (key A) and possibly some other obtained information when obtaining a verification key (key B) from a service point, such as a factory.

The user inputs the obtained verification key via the user interface to the device.

The device determines if the verification key B is a proper response to the request key, and if it is, grants access to the device.

DRAWINGS

In the following, the invention will be described in greater detail by means of some embodiments with reference to the accompanying drawings, in which

Figure 1 shows an embodiment of method;

Figure 2 shows an embodiment of the inputs to the algorithms; and Figure 3 shows an embodiment of a device. DETAILED DESCRIPTION

Figure 1 shows one embodiment of a method. In this embodiment is assumed that an administrator arrived to an electric station, attempts to get an access to a protection and/or automation device of the station but has forgot- ten the access password of the device. The case may also be that the administrator has changed and the new administrator is unaware of the password used by the previous administrator.

Figure 1 illustrates a procedure for generation of a one-time unique password to access the device.

As a first step in 1 -2, he gives a certain predefined key combination on the LHMI of the device.

In 1 -4, the device logic receives the key combination and checks its validity. If the key combination is valid, the device generates a request key (key A).

The device may use a time limit in the one-time password generation. That is, when the one-time password generation has been initiated, the device may start a timer during which the procedure should be completed. The time limit may be one hour or one day, for instance. In that case, if the procedure is not finished within an hour, for instance, the process needs to be re- started.

In 1 -6, the key A is provided to the user on the display of the device. The key A is unique provided that the previous key A and the corresponding verification key were used. The uniqueness of Key A may be accomplished by utilizing a step counter in the generation of key A.

In addition to key A, one or more pieces of information may be given from the device to the user. Such information may include a serial number, a MAC address or the type of the device, for instance. The additional information of the device can also include information that can be read from the outer case of the device, such as a device identity. In an embodiment, the user may have some further information that is not known by the device and cannot be read from the case of the device. An example of this kind of information is a purchase code of the device.

In 1 -8, the user contacts a service point, which may be a factory responsible for the manufacture of the device or a service desk responsible for administration and user support regarding the device. The contact may be car- ried out by the user establishing a voice connection to the service desk by using a mobile phone, for instance.

The service point asks the service man the request key and may additionally ask him/her one or more questions attempting to identify the caller. As further information, the service point may ask from the user one or more pieces of information disclosed in 1 -6 above.

In 1 -10, the service point generates a verification code (key B) by using a verification key generation algorithm. In the generation of key B, key A is used as an input. Additionally, one or more parameters that have been ob- tained from the caller may be used in the generation of key B.

In the generation of key B, the uniqueness of key B may be assured. That is, it may be taken into account that the disclosed password provision is applied more than once for a certain device and that key B is different each time. As explained in 1 -4, the key A may be unique, whereby also the resulting key B will be unique. Alternatively, the step counter may be implemented to key B generation.

Finally in 1 -12, the service point provides the generated key B to the caller.

In 1 -14, the user inputs the received key B to the device. I n 1 -16, the device checks if the inputted key B is an acceptable/proper response to the key A created in step 1 -4. The device may use the same algorithm as the service point, in which case the checking key given by the device algorithm is the same as the verification key generated by the algorithm of the service point. Alternatively, the device may have an algorithm, which takes key B as an input and generates key A. The algorithm may also input key A and key B and evaluate and output whether they form a proper pair of codes together.

In 1 -18, the device checks if the received verification key B is a proper response to the previously submitted request key. If so, the device pro- vides an access to the user, otherwise the access is denied. After the access to the device, the user may perform normal setting operations on the device, such as change a value of an operating parameter, and change his password, for instance.

There are certain situations, where the procedure does not proceed as disclosed above. For instance, the user may request key A, but does not use it in the device for obtaining access to the device. In this case, the device may provide the same key A also next time it is requested from the device. That is, a certain request key may be repeated in the device until it is used. When a certain key A has been used by inputting the corresponding verification key, the next key A given to a user is unique and different from the previ- ous one.

The users may have different access rights. Some users may only be entitled to view data of the device. Some others may have a right to configure data on the device. An administrator level may be the highest level. A user on this level may be entitled, for instance, to reset passwords on the lower lev- els. The password provision process disclosed in Figure 1 may be user group - specific. Each user group may have an own key combination to get a user group -specific key A, which correspondingly results into key B's by user group.

Figure 2 highlights the inputs to different phases of the generation of the one-time password. Initially, the generation of the one-time password starts with a user giving a predetermined input (input_key) for the device. Thereafter, two algorithms are applied, one for provision of key A, and one for verifying whether an access to the device can be granted or not.

Upon reception of the predetermined input, the device starts the provision of a request key (key A). The request key may be generated by using a generating algorithm, or alternatively, the device may have a look-up table storing a plurality of key A values, wherefrom the next available key A is read.

In an embodiment, the key A generation may take one or more dynamic parameter(s) (dyn_par) as an input. The dynamic parameter may be a step up counter or the date and/or time, for instance.

In an embodiment, the device may use also one or more static parameters (stat-par) when generating the key A. The static parameter may refer to a device identity, for instance.

When the user has obtained the key B from the service point, it is validated/verified in the device. The device receives the key B via the user interface of the device and verifies if the key B is a valid response to the previously provided key A.

There are various alternatives how the verification is carried out. In an embodiment, the device has a similar algorithm as the service point/factory, which generates the key B from the key A. The device may then compare the received key B and the generated key B to each other and verify if they match. In an alternative embodiment, the algorithm in the device is inverse compared to the algorithm applied at the service point. That is, the device may have an algorithm that inputs key B and returns key A. In such a case the device may compare the key A from the algorithm to the request key originally generated by the device. In a further embodiment, there may be a verification algorithm that does not output any of the keys, key A or key B, but outputs the verification result only, that is whether an access can be granted or not.

As to the input parameters, the verification algorithm takes key B and may take one or more of the key A, one or more dynamic parameters and one or more dynamic parameters.

In the above embodiments, the key B generation algorithm may carry out one or more of combining the input parameters in whole or in part, performing arithmetic operations on the input parameters, mixing the order of symbols in the input parameters, and adding or removing one or more symbols to/from the parameters, for instance.

Figure 3 shows an embodiment of a device 300. The device may be a protection and/or automation device of a power system, for instance.

The device comprises a user interface 302. The user interface may comprise a LHMI including a keyboard, a display and possibly other units for enabling the user to give input and receive output from the device. The user interface may also include a wireless communication module. A user may access the device by using wireless communication link between a laptop of a device and the device, or by dialing/calling the device using a mobile phone. The user interface may also have a wired communication interface. The device may be connected to a virtual private network of an operator, for instance. In this way an operator of the power system may establish a distance connection to the device.

The device may also include an initiation module 304 for initiating the generation of one time secure maintenance password. The initiation mod- ule evaluates, if the input key given by a user/administrator equals a predetermined key combination for initiating the password generation procedure.

The device may also include a request key generation module 306. The module 306 may include an algorithm that generates the request key (key A) or a lookup table from where the request key be read from. In the genera- tion of key A, one or more dynamic and one or more static parameters may be utilized as input parameters. The dynamic parameters may include one or more of a date, time of day or a step counter, for instance. The static parameters may include a device serial number or some other device-characterizing parameter. The generated key A may include one or more numbers and/or small/capital letters and/or special characters.

The request key generation module 306 may also be responsible of providing one or more additional parameters, in addition to key A, to a user of the device. Examples of such parameters are the user identity and a MAC code of the device. The module 306 cooperates with the user interface module 302 to output the key A and/or the additional parameters via the user interface of the device.

The device also includes a verification module 308 for verifying the verification key received via the user interface of the device. The verification module verifies if the received verification key is a correct response to the previously submitted request key. The verification may be carried by comparing the verification key to a stored key, or by checking the verification key by using a verification algorithm.

The device further includes an access module 310 which is cooperates with the verification module. If the verification module indicates that the verification key was correct, it grants access for the user to the device. Other- wise the access is denied.

Figure 3 shows also a protection module 312, which includes the functionality needed to perform protection functionality of the device. The protection functionality may be, for instance, overcurrent or overvoltage protection.

There is provided an input/output module 314, which is responsible for communication towards the power system. Via the input/output module, the device may receive power system signals, and output signals for triggering the protection functionality when needed.

The control module 316 includes functionality needed to coordinate the functionality of the device, such as coordinating the cooperation of the modules 302 to 314.

In accordance with an exemplary embodiment, such as Figure 3, the protection device may comprise a processor, which can be a general- purpose processor configured to execute a computer program tangibly recorded on a non-transitory computer-readable recording medium, for example, a ROM, hard disk drive, optical memory or flash memory. In this case, the general-purpose processor can be configured to carry out the operative func- tions described herein by executing the computer program recorded on the non-transitory computer-readable recording medium. In accordance with an exemplary embodiment, the processor can be an application specific processor that is specifically configured to carry out the operative functions described herein. The non-transitory computer-readable recording medium can be a memory resident in the protective device and/or communicatively connected to the protective device.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The in- vention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. A power system device, characterized in that the device comprises:

means for receiving (302, 304) a predetermined user input from a user of the device;

means for providing (306) a request key upon the received predetermined user input;

means for outputting (302) the request key for the user of the de- vice;

means for receiving (302) a verification key from the user of the device;

means for evaluating (308) if the verification key is an acceptable response to the request key that was provided for the user; and

means for providing (310) access for the user to the device if the evaluation indicates that the received verification key was acceptable.

2. A power system device according to claim 1, characterized in that the device comprises:

means for providing (306) the request key by generating or by reading it from a lookup table.

3. A power system device according to any preceding claim, characterized in that the device comprises:

means for providing (306) a request key that is unique until a verification key associated with the request key is input to the device.

4. A power system device according to any preceding claim, characterized in that the device comprises:

means for generating (306) the request key based on one or more of the following one or more dynamic parameters, one or more static parameters.

5. A power system device according to any preceding claim, characterized in that the device comprises: means for evaluating (308) if the verification key is an acceptable response to the request key by using an algorithm which inputs one of the keys as an input and provides the other key as an output.

6. A power system device according to any preceding claim, characterized in that the device comprises:

means for generating (308) a checking key based corresponding to the verification key based on the request key and one or more of the following: one or more dynamic parameters, one or more static parameters.

7. A power system device according to any preceding claim, characterized in that the device is a protective relay.

8. A power system device according to any preceding claim, characterized in that the device comprises a local user machine interface for receiving input from and giving output to user.

9. An access verification method for a power system device, characterized by:

receiving (1-2) a predetermined user input from a user of the device; providing (1-4) a request key upon the received predetermined user input;

outputting (1-6) the request key for the user of the device; receiving (1-14) a verification key from the user of the device;

evaluating (1-16) if the verification key is an acceptable response to the request key that was provided for the user; and

providing (1-18) access for the user to the device if the evaluation indicates that the received verification key was acceptable.

10. An access verification method according to claim 9, characterized by comprising:

providing (1-4) a request key that is unique until a verification key associated with the request key is input to the device.

11. An access verification method according to any preceding claim

9 or 10, characterized by comprising: evaluating (1-16) if the verification key is an acceptable response to the request key by using an algorithm which inputs one of the keys as an input and provides the other key as an output.

12. An access verification method according to any preceding claim 9 to 11, characterized by comprising:

generating (1-16) a checking key based corresponding to the verification key based on the request key and one or more of the following: one or more dynamic parameters, one or more static parameters.

13. A computer program product configured to perform the method according to any preceding method claim 9 to 12 when run on a computer.