| ||||
| ||||
| Есть две программы. Первая стоит на клиентских машинах, вторая на сервере. Задача первой программы - перегружать некоторый сервис по требованию второй программы. Задача второй - коннектится к первой и посылать команду. Вопрос: как первой программе аундифицировать вторую ? и можно ли вообще говорить о серьезной защите при таком расположении вещей? п.с. пытаюсь это сделать с помощью OpenSSL, но все трудность заключается в том, что исходя из идеологии сокетов _серверное_ приложение (accept) находится на клиентской машине там же и private ключ... | ||||
| Ответы: | ||||
| ||||
| Наверно решение можно найти. Можно например посмотреть на предложения по аутентификации приложений от Common Data Security Architecture (CDSA)и на этой схеме что то придумать. Описано это так. Integrity Services CSSM provides a set of integrity services used by CSSM, module managers, add-in modules, and applications to verify the integrity of themselves and other components in the CSSM environment. The dynamic, configurable environment defined by CDSA and supported by CSSM provides the level of service and flexibility that applications require. In balance with the benefits are the increased risk of introducing tampered components into the environment. To address this, CSSM provides a set of integrity verification and identity verification functions. CSSM also requires their use during each dynamic reconfiguration of the CDSA environment. CSSM-Enforced Integrity Verification CDSA checks the integrity of modules as they are dynamically attached to the system. A bilateral authentication procedure is designed for two entities to establish trust in the identity and integrity of each other. When attaching an add-in module or an elective module manager, CSSM requires that the attaching party participates in a bilateral procedure to verify the identity and the integrity of both parties. If authentication fails, the module is not attached and system execution is interrupted. Both parties in the bilateral procedure must have three pieces of signed credentials: A certificate, signed with a valid, recognized manufacturer A manifest object that aggregates all of the sub-components and attributes describing the capabilities of the component, signed with the component’s certificate A set of object code modules, signed with the component’s certificate These credentials are stored in the local file system and are associated with the component. CSSM’s credentials are also placed on the system during installation. The credentials of a dynamic component are placed on the system when that component is installed with CSSM. As part of attach processing, CSSM performs the first half of the bilateral protocol, which proceeds as follows: Locate the component’s credentials in the local system Verify the component’s certificate and manifest Load the component’s object code and verify it signature Determine that the component’s initial entry point is within the checked object code (ensuring secure linkage) and invoke the verified component The component completes the authentication procedure as follows: Self-check the object code signature Locate CSSM’s credentials in the local system Verify CSSM’s certificate and manifest Verify the object code signature for the loaded CSSM Determine that your return address for CSSM is within the checked CSSM object code (ensuring secure linkage) Complete attach processing and return to CSSM When the three credentials verify, it is still necessary to ensure secure linkage between the components. For the CSSM, this entails checking that the called address is in fact in the appropriate code module. For the attaching component, the return address must be verified to be within the CSSM calling module. (Even in the case of self-checking, one may require that the return address be within the module being checked.) Linkage checks prevent attacks of the stealth class, where the object being verified is not the object that is being used. Also, the checks increase the difficulty of the man-in-the-middle attack, where a rogue component will insert itself between two communicating modules, masquerading itself as the other component to each component. Bilateral authentication should also be performed between applications and CSSM. This requires a manufacturing, installation and start-up process in which applications can: Create credentials of the same form as add-in modules and elective module managers Voluntarily place their credentials on the local system during application installation Perform their half of the bilateral authentication process with CSSM Applications that do not want to implement or cannot implement the entire bilateral procedure can still benefit from CSSM integrity services by invoking selected CSSM integrity functions to: Perform a self-integrity check Check the identity and integrity of CSSM Check the identity and integrity of add-in service modules | ||||
anonymous