E-Net Models of a Software System for E-Mail Security

This paper presents solutions for cryptography protection in MS Outlook. The solutions comprise the authors’ experience in development and implementation of systems for information security in the Automated Information Systems of Bulgarian Armed Forces. The architecture, the models and the methods are being explained.

💡 Research Summary

The paper addresses the growing need for robust email security within corporate and military information systems, focusing on the limitations of existing solutions such as PGP, S/MIME, and certificate‑based approaches. The authors propose a comprehensive software suite that integrates a Windows‑based cryptographic middleware called CSSW (Cryptographic Software for Security in Windows) with a plug‑in for Microsoft Outlook (versions 97/2000). CSSW provides a full stack of security services: user authentication, access control, symmetric and asymmetric encryption, digital signature generation and verification, logging of all security‑relevant events, and automated report generation.

The overall architecture is divided into four functional modules: (1) an end‑user module that includes the Outlook plug‑in and a SecMail application, (2) an email serving module that handles message transport, (3) a control and monitoring module that oversees system activity, and (4) a cryptographic key distribution and management module. The authors illustrate the message flow with a schematic (Fig. 1) showing how a user composes a message, the message is encrypted by a local crypto server, stored in a database, and finally transmitted to the recipient, who follows the reverse process to decrypt and read the mail. Every step is logged, and the logs can be aggregated into audit reports.

To formalize the dynamic behavior of the system, the authors introduce two E‑net (extended Petri‑net) models: ENS for “preparing and sending a message” and ENR for “receiving and working on a message.” ENS consists of 15 transitions (t1‑t14) and a set of places (bp1, br1‑br4, b1‑b15). The transitions model actions such as request for access, rights verification, local crypto‑server check, SecMail resource request, logging, recipient selection, encryption, database storage, sending, and system exit. The “permissive places” (br1‑br4) act as guards that enable specific transitions only when the system is in an authorized state. ENR mirrors the receiving side with 12 transitions (t1‑t12) and places (bp1, br1‑br5, b1‑b11), covering access request, rights verification, new‑mail checking, SecMail request, logging, message selection, secure mail receipt, and termination. Both models define kernel functions (F and H) that map the flow of tokens between places and transitions, thereby providing a mathematically precise description of the security workflow.

Implementation details reveal that the Outlook plug‑in was built for Outlook 97/2000 and communicates with CSSW through a defined API. The plug‑in intercepts outgoing mail, invokes CSSW to encrypt the payload, stores metadata (subject, body, attachments) in a secure database, and forwards the encrypted blob to the recipient’s mail server. On the receiving side, the plug‑in detects encrypted messages, calls CSSW to decrypt, verifies digital signatures, and presents the clear text to the user. All operations generate entries in a centralized log, which can be queried for compliance audits. The system was evaluated by the Information Security Laboratory of the Defense Advanced Research Institute and received internal approval.

Despite its contributions, the paper exhibits several shortcomings. The E‑net models, while formally defined, lack concrete examples linking model elements to actual code modules, making it difficult for practitioners to adopt the approach directly. Critical cryptographic parameters—algorithm choices, key lengths, certificate lifecycle management—are omitted, leaving security strength open to interpretation. The reliance on outdated Outlook versions raises compatibility concerns for modern environments (e.g., Outlook 365, web‑based mail clients). Moreover, the authors provide no performance benchmarks, scalability analysis, or penetration‑testing results, which are essential to validate the system’s resilience against real‑world attacks.

In summary, the work presents a novel integration of a dedicated cryptographic middleware with a widely used email client, and it formalizes the security processes using E‑net models that could support formal verification and systematic testing. The modular architecture, comprehensive logging, and automated reporting address many of the gaps found in traditional email security solutions, especially in high‑security domains such as military information systems. Future research should extend the models to multi‑user, multi‑domain scenarios, update the client side to support current email platforms, and provide rigorous security and performance evaluations to substantiate the claimed benefits.