semi合集-English.pdf - 第3350页

SEMI E132-0305 © SEMI 2004, 2005 3 7 Conventions 7.1 Unified Modeling Languag e (UML) Notation — All class and sequence di agrams in this standar d make use of the Unified Mod eling Language notation. 7.2 Attribut e Tabl…

100%1 / 7923
SEMI E132-0305 © SEMI 2004, 2005 2
6 Terminology
6.1 Definitions
6.1.1 administration — the process of configuring equipment client identities, associated credentials, and setting
authorizations.
6.1.2 Asymmetric Key Cryptography — see Public Key Cryptography.
6.1.3 authenticated communications — communications with equipment compliant to this specification to establish
an authenticated session, to grant authorizations and for administration. This includes any communications over the
authenticated session. Note that authenticated communications are not necessarily encrypted.
6.1.4 authenticated session — also referred to as session in this document, this is an application-level concept
defined by this specification and is independent of any physical or logical connection or communication protocol
“session” layer used in the actual exchange of messages. An authenticated session or session follows the session
establishment procedure, state models, and the defined services as described in this specification.
6.1.5 authentication — the process of determining whether a user or process is, in fact, who or what it is declared to
be. In private and public computer networks, authentication is often achieved through the use of passwords.
Knowledge of the password is assumed to guarantee that the user is authentic. This standard refers only to the
authentication of application processes, and does not support or address authentication of human users.
6.1.6 authorization — the process of granting the privilege to perform a specific action to a user or process. Note
that the user or process must be authenticated before authorization may take place.
6.1.7 client — an application process that communicates with the equipment to access equipment resources. This
specification uses the terms “client” and “client application” interchangeably.
6.1.8 communication session — a series of two-way message exchanges between a client and the equipment. A
session typically begins and ends at the request of the client.
6.1.9 cryptographic algorithm — a transformation of meaningful data into some meaningless data, a process called
encryption. If the transformation is reversible, then the reverse process is called decryption. Typically it is
computationally difficult to correctly decrypt the data without knowing both the algorithm used and some additional
information, referred to as keys.
6.1.10 encryption — see cryptographic algorithm.
6.1.11 message digest — see one-way hash.
6.1.12 one-way hash — a one-way transformation of an arbitrary length of data into a fixed-length code. The
transformation is computationally difficult to reverse, and unlikely to have collisions. The same message will
always result in the same hash, and any slight modification to the original message will result in a different hash,
thus providing message integrity. The terms One-way Hash, Hash and Digest are used interchangeably in this
document.
6.1.13
Persistent Session — an Authenticated Session established that survives equipment shutdowns or power offs,
it is set to persistent by a client through an equipment service defined in this specification. Behavior of a persistent
session during equipment shutdown and startup is as defined by the session state model described in this document.
6.1.14 Public Key Cryptography (PKC) — also known as Asymmetric Key Cryptography, a cryptographic
algorithm that employs two keys for encryption and decryption of data. One key is designated as the public key and
can be freely advertised, while the other key, designated as the private key, is never revealed. Data encrypted with
one key can only be decrypted with the other key. PKC is widely used for key exchange and message signing.
6.1.15 Secret Key Cryptography (SKC) — also known as Symmetric Key Cryptography, a cryptographic algorithm
that employs one single key for both encryption and decryption. SKC is widely used for bulk encryption of data due
to its speed over PKC.
6.1.16 Session — in this document, the term “session” refers to an Authenticated Session unless specified otherwise.
It has no relation to the sessions that may be defined elsewhere.
6.1.17 Symmetric Key Cryptography — see Secret Key Cryptography.
SEMI E132-0305 © SEMI 2004, 2005 3
7 Conventions
7.1 Unified Modeling Language (UML) Notation — All class and sequence diagrams in this standard make use of
the Unified Modeling Language notation.
7.2 Attribute Tables — The table below provides an example of the tables used to list and describe attributes of
classes defined in this specification.
Table 1 Attribute Table Format
Attribute Name Definition Form
See list below.
7.2.1 Form — Defines the data type of the attribute. The terms used to describe data types used 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.
7.2.2 Association Tables — The table below provides an example of the tables used to list and describe associations
between classes defined in this specification.
Table 2 Association Table Format
Association Role Name Definition Comments
7.2.2.1 Association Role Name — The name of the association role being specified.
7.2.2.2 Definition — Describes the function or purpose of the association.
7.2.2.3 Comments — Any additional comments or notes regarding the association.
7.3 Operation Definition Tables — The table below provides an example of the tables used to list and describe the
interface operations defined in this specification.
Table 3 Operation Definition
Operation Description Type Requestor/Sender Responder/Receiver
See list below.
7.3.1 Operation — Specifies the name of the operation.
7.3.2 Type — Specifies the messaging semantics of the operation. Only Request-Response (RR) and Fire-and-
Forget (FF) semantics are used in this specification.
7.3.3 Requestor/Sender — For RR semantics, identifies the entity that makes the request, for FF semantics,
identifies the entity that sends the message. Can be ‘Client’, ‘Admin’, or ‘Equipment’. Client can be any of the
applications communicating to equipment compliant to this specification.
7.3.4 Responder/Receiver — For RR semantics, identifies the entity that responds to the request, for FF semantics,
identifies the entity that receives the message. Can be ‘Client’, ‘Admin’, or ‘Equipment’.
7.4 Operation Argument Definition Table — The table below provides an example of the tables used to list and
describe arguments for interface operations defined in this specification.
Table 4 Operation Argument Definitions
Argument Description Kind Form
See list below. See list below.
7.4.1 Argument — Specifies the name of the argument.
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.