semi合集-English.pdf - 第3353页

SEMI E132-0305 © SEMI 2004, 2005 6 communicate the creden tials will not be defined in this docume nt, an d may be as simple as configurations inside the client application. 9.2.2 Client — The client holds any issued cre…

SEMI E132-0305 © SEMI 2004, 2005 5

consoleconsole

The HSMS-SS approach: only accept first connect request

wrong

client

right

client

wrong

client

right

client

wrong

client

right

client

wrong

client

right

client

Right client attempts to connect

first, is granted access

Right client attempts to connect

second, is denied access

Figure 3

First-come First-served Communication

8.4 A more secure technique to ensure that only authorized clients are allowed to utilize equipment resources is to

require clients to first prove their identity to the equipment. If the equipment knows a client’s identity, then the

equipment may be able to assume that the client is authorized to proceed with further requests.

9 Overview

9.1 This standard defines a mechanism for clients of manufacturing equipment to authenticate to the equipment prior

to any subsequent communication. To facilitate this, both the authentication procedure itself and a means for

establishing client identities with the equipment beforehand must be defined. This standard also defines a flexible

scheme for authorization and mechanisms to support a centralized administration model.

9.2 Central Administration Model — A conceptual view of a central security administration model is presented in

Figure 4 below.

Credentials/Authorizations Mgmt

Client Credentials/

Authorizations

Authenticate

Security

Admin

Equipment

Client

Authentication/

Authorization Interface

Credentials/Authorizations Mgmt

Client Credentials/

Authorizations

Authenticate

Security

Admin

Equipment

Client

Authentication/

Authorization Interface

Figure 4

Security Administration Model

9.2.1 Security Admin — The security admin issues client credentials, establishes client authorizations and possibly

client credentials on the equipment, defines custom roles and their authorizations. Client credentials are identifying

information for the client. The security admin manages equipment authorizations and client credentials using an

administration interface defined in this specification. The interface between security admin and client to

SEMI E132-0305 © SEMI 2004, 2005 6

communicate the credentials will not be defined in this document, and may be as simple as configurations inside the

client application.

9.2.2 Client — The client holds any issued credentials assigned to it, and authenticates to the equipment to establish

an authenticated session.

9.2.3 Equipment — The role of equipment in the administration model is to establish the security admin entity for

the equipment, hold any defined authorizations, authenticate clients to establish a session, determine client

authorization levels and enforce them for the established session.

9.2.4 Interfaces — The authentication, administration, and session establishment interfaces will be defined in later

sections along with the concepts of establishing client identities and authorizations, though the actual technology

and protocols used maybe defined in further detail in a separate adjunct standard.

9.3 Challenge/Response Authentication

9.3.1 The authentication process begins when a client first attempts to establish a communication session with the

equipment. Upon receiving this request, the equipment challenges the client to prove its identity to the equipment.

The client must encrypt some session-generated data using a private or secret key (e.g. a password) that only the

claimed client would know. The equipment can verify client’s claim using the corresponding public key or shared

secret key assigned to the client to decrypt the data, if decrypted data matches plaintext then client is verified.

9.3.2 For communication technologies in which a separate outgoing connection must be established in order for the

equipment to send events, the equipment must also verify that the receiving address is valid. This is achieved by

sending a ping message to the client endpoint (see Section 15.1.1). This specification currently does not define a

mechanism by which a client can transfer an established session to a different endpoint.

9.4 Authorization

9.4.1 Any client application wishing to invoke privileged services on the equipment must be authorized to do so.

Authorization is implemented by granting access control privileges beforehand to defined clients and later checked

against the client’s requests. The general operational flow is as follows:

 Authentication and Credentials Exchange — Client application authenticates to equipment as to its identity and

establishes an authenticated session.

 Session Established — Equipment optionally caches client application’s privileges and associates these

privileges with the newly-created session.

 Service Request — Client application makes a service request.

 Privilege Validation — Equipment validates the client application’s request against its assigned privileges.

 Session Closed — Client application closes session, all session state information are reset or cleaned.

9.4.2 Since the client does not authenticate itself for each service request, privilege validation is performed against

the authenticated session created for that client. This does not necessarily mean that the implementation of a session

requires the use of a stateful or connection-oriented communication protocol, or that authentication must be

performed during every protocol-level reconnect. If the implementation protocol is connectionless, the session can

be identified by some mutually agreed upon session identifier, negotiated during the authentication process required

to establish a session.

NOTE 2: This specification does not define a mechanism for controlling end-user access to equipment services or information.

The authentication and authorization scheme defined in this specification applies at the application level only. Management of

end-user access to equipment functions and information is strictly the responsibility of applications that make use of the

authenticated communication sessions defined in this specification.

10 Authentication

10.1 Authentication Message Flow — The authentication message flow during a normal session establishment is

presented in Figure 5. Arrows represent the major messages exchanged during the handshake, with side notes

clarifying the key data exchanged in each message. Depending on the actual messaging/transport protocols and

encryption algorithms used, some additional messages or data parameters may be added, but the concept remains the

same. Specifics of algorithms and protocols will be detailed in a separate technology mapping specification. The

terms server and equipment are used interchangeably.

10.1.1 Session Request — This message requests the equipment to initiate establishment of an authenticated session.

Upon receiving this message, the equipment begins the authentication handshake as shown in Figure 5. If the

request is not accepted, the equipment responds with a protocol specific alert or error message and terminates the

connection, see Equipment Challenge.

10.1.2 Equipment Challenge — After the session request is accepted, the equipment responds with a challenge. The

equipment selects the algorithms to be used for authentication (if applicable), provides its own identification and

challenges the client to authenticate itself. The challenge can be a simple request to client to prove its identity. Note

that errors can be returned instead of the normal parameters. Additional errors may be needed as required by the

implementation protocol used to support the concepts.

10.1.3 Client Authenticate — The client responds to the server challenge, confirming the algorithms selected (if

applicable), equipment’s identification and also presents proof of client’s own identity. The proof is typically a hash

of some random data encrypted with a key that only the client would know and that the server can verify. A secret

unique to the authentication protocol may also be generated by the client and sent to equipment in the response.

Actual algorithms used for exchange of this secret will be defined by the specific authentication protocol specified in

the adjunct standard.

Client Equipment

Session Request

Equipment Challenge

- Algorithms

- Equipment ID

- Challenge

Client Authenticate

- Client Id

- Session Secret

- Client Id Proof

Client Authenticated

Equipment ACK

- ACK

Session

Authenticated

Client Verify

Equipment Verify

Figure 5

Authentication Message Flow

Table 5 Equipment Challenge Parameter Definitions

Parameter Description Kind Form

Algorithms Identifies the cryptographic algorithms to be used for key

exchange, one-way hash functions and data encryption.

OUT Text, with delimited

fields to identify the

algorithms used.

Equipment Id Equipment identity, exact format as defined by the protocol chosen,

and can be as simple as a name identifier such as in a password-

based scheme.

OUT Text.

Challenge Request for client to authenticate itself, contains random data for OUT Text.