\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline \hline
**Key Management Operations** & **Purpose** \\ \hline Key generation & Create keys \\ \hline Key distribution & Deliver the generated keys to the intended recipient. \\ \hline Key establishment & Communicating parties must hold the key or parameters to generate the keys. \\ \hline Key storage & Safeguard the active keys that are used for cryptographic services. \\ \hline Key backup & Keep a copy of the keys. \\ \hline Key update & Replace the existing keys with new keys, when the crypto period of the key is expired or when the crypto keys are compromised. \\ \hline Key recovery & Retrieve the lost keys from backup or archival storage \\ \hline Key revocation &
\begin{tabular}{l} Invalidate the keys of the user/device which is compromised or when the crypto period of key is near to expiry or when user/device leaves the network. \\ \end{tabular} \\ \hline Key disposal & Remove the key permanently from all the sources (user, backup and archival) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Key management states. constraints. Based on the constraints, there is a need to choose appropriate crypto algorithms. In the proposed design, we deploy a symmetric crypto system for lower level devices (polynomial and matrix method) and an asymmetric crypto system for higher level devices (Elliptic curve crypto system). * Modification of configuration parameters at one level of IACS should not disturb other levels. If the plant operator wants to configure or make changes in security parameters of the device or identify any compromise, the disruption or changes made at one level of IACS devices should not disturb the operations of other levels IACS devices. Since the proposed design uses different schemes for each level, the mentioned issue can be resolved easily. * Reduce the damage caused from attacks. The impact of attack at one layer of IACS should be minimized on rest of the network. With the use of separate crypto system for each level of devices, the impact of any attack confines only to that level. Thus reducing the time required for recovering from the attack and reinstalling the fresh parameters. * Use a separate crypto system for each level of IACS devices. Polynomial method is chosen for field level devices, matrix method for control level devices and ECDH for plant level devices. These schemes are basically meant for establishing secret keys between the communicating devices, but we have used the same methods to support other key management operations such as key update, device joining, key revocation, key storage, archival, key recovery and key de-registration and destruction. * Simplify the key update, key revocation, device addition and deletion operations. It is observed in the literature that the key update and key revocation of a device affects the entire system. In the proposed design, separate crypto system is employed for each level of the IACS. Key update and key revocation for particular level devices should not disturb the entire network. Device addition and deletion can also be easily handled. The rest of the paper is organized as follows: Section 2 discusses the related work. Section 3 gives the preliminaries. Section 4 proposes a novel key management infrastructure for IACS. Section 5 highlights the CKMI design and its features. Section 6 is devoted to the performance evaluation of the proposed design. Section 7 gives the conclusion of this work.