FBI Criminal Justice Information Services Division Next Generation Identification

Rap Back
Rapid Mobile
Iris
Facial
Latents
Palms

 Universal Face Workstation (UFW)

* FBI user software to support access to NGI Face Pilot and NGI System face search capabilities
* Cross Platform (Windows, OSX, Linux)
* Built upon a Biometric Integration Platform
* Built on open source frameworks
* Extensive support for plugins
* Will be available for Law Enforcement use free of charge

UFW Objectives

Plan, design, prototype and demonstrate a face workstation which can be freely deployed by the FBI

* Develop services which can be carried over to NGI for biometric processing

* Employ a user experience design philosophy to develop UFW specifically for face examiners

Permit examiners to:

* Ingest, analyze and enhance images

* Select sub-frames or sub-images areas for further analysis

* Submit files to local and remote matching systems

* Review, store and match search results

DOWNLOAD 
PDF  30pg   2.26mb

Introduction  

If you usually typing a password in a desktop application, it may be that a keylogger spies out your secrets. This is obviously not good. Screen keyboards might be a good solution, but again, there could be a screen capture program which watches effortlessly your passwords. Furthermore, screen keyboards are relative unhandily.
The following article presents a relatively simple principle, which prevents the keylogger to write down passwords entered. Basically, the used system is surprisingly easy and can therefore be transferred to other programming / operating systems / platforms, although under a small limitation.

Background 

The first question is: How can a program hide keystrokes? Perhaps there are some difficult ways to do this, but most probable this is not possible. We create an assumption: Entered characters necessarily mean the keylogger sees them. And that's what we use against the keylogger.
The second question is: How can a program generate keystrokes? This is normally possible. For example, we use in C# the class SendKeys, which provides methods for sending keystrokes. By the way, there can be the mentioned limitation because a website has not the authorization to produce keystrokes.
The third question is: How can we combine these two statements? At every time when the user types a character, the program generates some keytrokes more. The keylogger write down all characters both from user and program, but only the user and the program know the entire password. Unauthorized third parties see only letter salad and they can not decrypt the main password.
The fourth question is: Is this main system 100 % secure? Surprisingly and unfortunately no. The prinziple has many weak points, but there are also many solutions to close these gaps. I advise every developer to think about it before they add this concept to their code. Let me explain you the vulnerabilities and the solutions:

1. Creating random keystrokes after every character allows attackers to reproduce the typed password. Therefore the program must create identical keystrokes. Then again the produced keystrokes should not be identical for all passwords. In summary, we need a algorithm, which produces for every character always the same keystrokes. In addition to this, the length of the generated keystrokes should vary.
2. For all that, an attacker can create a table with all characters and their hash result either by reverse engineering or by testing. Using this table, he can decrypt the password relatively easy. To prevent this, the generated keystrokes should depend on a password identity, such as account name, account number, e-mail or computer specification. Unfortunately, this is only an obstacle, but no blockage for attackers.

Download 

 Mediafire-download

 

 Credit: Michael Hudak -SourceCode