semi合集-English.pdf - 第3352页
SEMI E132-0305 © SEMI 2004, 2005 5 c ons ol e console c ons ole console co ns ole console co nso le conso le The HSMS-SS approach: only accept first connect request wrong client right client wrong client right client wro…
SEMI E132-0305 © SEMI 2004, 2005 4
7.4.2 Kind — Specifies whether the argument is an ‘in’, ‘out’, or ‘error’ argument for the operation. ‘error’
arguments always function as ‘out’ arguments, but indicate that the operation did not complete successfully. Not all
errors possible for a specific operation will be listed, only select typical ones are.
7.4.3 Form — Defines the data type of the argument. The terms used to describe data types in this column are
defined in the SEMI Compilation of Terms, or are included as part of the specification. Refer to the compilation of
terms for the definition of SEMI type name meanings.
8 Background
8.1 In conventional semiconductor equipment communication, such as that defined by SEMI E30, it is assumed that
only a single client application can gain access to the equipment for communication. This assumption was valid
when the physical transport medium was based on a serial cable connection to the equipment. In such an
environment, it is possible to ensure that only a single client application is permitted to interface with the equipment
by only providing the serial connection to the machine on which the application runs.
consoleconsole
Execute process
program
acknowledge
Figure 1
Equipment Communication via Serial Cable
8.2 As equipment communication moves from a serial cable medium to Ethernet, it becomes possible for any client
on the network to send requests to the equipment, provided there is a path from the client node to the equipment.
Without taking specific measures to secure communication with the equipment, it is not possible to ensure that only
authorized clients are permitted to communicate with the equipment.
consoleconsole
A
uthorized Data Collection
Request
Unauthorized Data Collection
Request
Figure 2
Equipment Communication via Ethernet
8.3 Even if the equipment accepts only a single connection request from the network, it is still vulnerable to a race
condition among any clients that attempt to connect. This results in a “first-come, first-served” policy in which the
first client to attempt a connection with the equipment is granted access, even if that client is not authorized to
communicate with that specific equipment. Such an environment is insufficient for providing adequate protection of
equipment resources.
SEMI E132-0305 © SEMI 2004, 2005 5
consoleconsole
consoleconsole
consoleconsole
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