Application Development
Quantization without Bounding Box
Most data sets do not make use of full floating-point precision so that the lowest-order bits are noise and not actual data. For effective compression, floating-point positions are usually quantized onto a uniform grid. To support quantization for streaming meshes whose bounding box is not known in advance, we use a scheme that quantizes conservatively using a bounding box that is learned as the mesh streams by. The first two vertex positions are compressed without quantization and their distance gives the initial guess on the number of mantissa bits that need to be preserved to guarantee the user-requested precision. This maximum distance is updated with every compressed vertex position and will eventually match the extent of the actual bounding box. How long quantization is overly conservative depends on the order in which of the vertex positions are compressed.
This scheme is part of our current API and works reasonably well, but we still need to analyze and optimize compression speeds and bit-rates. Since conservative quantization encodes many positions with more precision than needed, thereby inflating compression rates, we want to use bounding box information if possible. For the results reported in this paper we assume that advance knowledge about the
bounding box is available. Our streaming mesh writer also supports lossless floating-point compression. This is less efficient since the low-order bits of the mantissa typically contain incompressible noise. But providing this functionality makes it possible to use compression when quantization—for whatever reason—is not an option.
Keyword Search Over Semistructured And Structured Databases
Keyword-based search is very useful for unstructured documents, and often is the onlyway to query such data. Keyword search also can be very useful over more structured data, since it is inherently simple for users to master and often is sufficient for the task athand. However, some IR concepts and algorithms must be reconsidered in a database setting. In particular, proximity search benefits from
a new approach in a database setting. Traditionally, proximity search in IR systems is implemented using the “ near” operator. If we search our document collection for “ Harrison Ford” near “ Carrie Fisher” , we are looking for documents where those two names appear “ close” to each other, where closeness is measured by textual proximity. In this sense, proximity search is a relatively simple,
“ intra-object” operation: we measure proximity along a single dimension (text) in each document. Now, suppose that we have fully migrated our movie document collection to XML. Each movie might begin with a MOVIE tag, followed by nested tags for that movie’s actors, producers, etc. In this setting,we want to account for “ structural proximity” in the database, while textual proximity may not be relevant. For example, if Harrison Ford and Carrie Fisher both star in the same movie, then they will both be sub-elements of a specific MOVIE element. In the textual representation, however, there may be many other actors lexically in between these actors. Similarly, we may find that the last actor listed for some movie X is textually close to the first actor listed for an adjacent movie Y— but this doesn’t mean that the two actors are related in any way. Thus, we need to extend the notion of proximity search to handle the structure inherent in a semistructured database. This work fills in Entry 4 in our matrix.
Algorithms and techniques for performing proximity search over a graph-structured (semistructured) database are applicable to a traditional relational or object oriented database as well. We can (logically) translate a relational database into a graph based on the schema and on primary/foreign key relationships. We can then use our proximity search techniques to measure the distance between database elements based on the graph representation. Viewing an object-oriented database as a graph is of course even simpler. By combining proximity search with traditional indexing techniques for identifying tables or attribute values that contain given keywords, we can provide keyword-based search (and browsing) for traditional databases. Thus, our work on proximity search applies to matrix Entry 2 as well.
JDK 1.2 Security model for smart card application deployment
JDK 1.2 security model differs from the “all” or “nothing” approach of the 1.1 model. Like the Microsoft or Netscape models, JDK 1.2 allows granting privileges in a very fine-grained matter. The process to create a certificate is also simplified. One keytool instruction declares a trusted entity, generates the keys and creates the certificate. The new keystore architecture replaces the identity database that java key created and managed. Note that you can now protect your keystore and your private keys with passwords. Once the applet is packaged into a JAR file using the jar tool, you can then sign the JAR file with the jarsigner tool.
Like JDK 1.1, the 1.2 security model is still not supported by your favorite browser and Sun released the Java Plug-in 1.2 and the HTML converter tool for the 1.2 security model. You will therefore need to convert your HTML file that hosts your signed applet. Unfortunately, configuring your local machine for the JDK 1.2 security model is as complicated as for Java 1.1. Before running the signed applet, the user must first install the Java Plug-in, select the JRE 1.2 and import the certificate of the trusted entity that signed the applet. There is an additional step: the user needs to update the policy file attached with the keystore to specify which privileges are granted to the entity that signed the applet. This java.policy file is initially located in the lib/security folder of the selected JRE 1.2.
// this keystore is to store our certificates
keystore “.keystore”;
// gives full privileges to applets signed by XLorphelin
grant signedBy “XLorphelin”
{
permission java.security.AllPermission;
};
Listing 1: Policy file for JDK 1.2 security model
To verify a signed applet, the JRE first refers to its java.security file located in lib/security. This file specifies where the java.policy file is located. The default is to have a single system-wide policy file in the lib/security folder and a policy file in the user’s home directory (C:\Winnt\Profiles\<username> for Windows NT platforms). This policy file provides the name and location of the keystore as well as determines what actions foreign applets signed by a specific entity are allowed to carry out on the user’s local machine. When using JDK 1.2 security model to load a terminal application, the user must carefully install the java.policy file and the attached keystore in the expected directory. Note that the java.policy file must be rename .java.policy (don’t forget the dot at the beginning of the file name) if located in the user.home directory. The opencard.properties file can either be installed in the user.home directory or in
the lib folder of the selected JRE.
6 Simple Steps to Beat Phishing
Everybody knows about phishing. Phishers impersonate a trusted web site, commonly a bank or an online payment provider, in order to extract confidential information from users. Not only unsuspecting consumers are the victims of these scams, but in addition, the impersonated web sites will be impacted by reduced consumer confidence into their product, as well as by financial losses due to the
misuse of the collected information.
1. Consistent Branding
For a consumer, the first and sometimes only way to tell if a web site or an email is trustworthy is the fact that either the URL or the layout “doesn’t look right”. In this context, it is important to provide consistent visual queues to end users to recognize communications from your business. In particular e-mail sent to customers should use the same ‘From’ domain name as you use at your website. If you outsource mass mailings, insist that these emails will still use the familiar ‘From’ address. Consumers will otherwise not be able to distinguish between obvious fakes and real e-mail. Assist customers in securing their systems by not requiring the use of Javascript and Active-X. In particular, design your web site to be accessible by various browsers.
2. Monitor bounces to customer facing e-mail addresses
In order to advertise their fake web sites, phishers typically use the same methods and address lists used for spam. Many of the e-mail addresses on these lists are expected to be invalid. If you use consistent ‘From’ addresses, the phisher will have to use this address to maximize success. This will result in some bounces being sent back to your own mail servers. Setting up a process to screen these bounces for phishing e-mail will provide an early warning mechanism to alert you of phishing scams.
3. Monitor referrers to public web sites
Phishers typically redirect the user to the authentic web site after the information has been collected. This is done to hide the phishing site from the user and to improve its plausibility. The web browser will send the URL of the phishing web site as part of its ‘Referrer’ header. Web servers can be configured to log this data, and most web servers already do so by default. Monitoring this log for unusual referrers will again assist in finding phishing websites.
4. Watermark web content
Phishers attempt to emulate the look and feel of your web site as good as they can. Typically, the HTML code and images from your site are just copied. As a result, the phisher will have to visit the authentic site before setting up the fake site. Encoding the IP address and a time stamp as part of your HTML code will likely allow you to figure out when the code was copied from your site, and who copied it. There are a numerous ways to accomplish this. Adding spaces between HTML tags, including extra GET parameters, or even watermarking images. The most appropriate method will depend on your web infrastructure.
5. Preposition countermeasures
Once you find a site impersonating you, there are a number of techniques you can use to limit damage. Most web servers will allow you to redirect users to special pages based on the referrer field sent by the browser. As phishing victims are frequently directed back to your site after they visited the fake site, you can use this technique to identify victims, or redirect them to a warning page. If they are existing customers of yours, you may be able to identify them based on prior cookies left behind by your site.
These countermeasures typically need to be prepared ahead of the phishing scam in order to evaluate the impact on web site performance. Once prepositioned, these redirects or special logs can be enabled quickly once a phishing site has been identified.
6. Organizational and Administrative Countermeasures
The company web site should include a link and contact information to report phishing or other security issues. All phishing countermeasures should be coordinated by a single individual.
Educating your customers about phishing, and showcasing samples for them to learn how to spot a phishing scam, will prevent them from becoming victims. If your web site allows access to critical financial or personal information (e.g. Banks, Brokerages), you should consider the use of strong authentication via hardware tokens. It will decrease your response time, to discuss legal implications ahead of time and to have a legal response laid out ahead of time (e.g. letter drafted to be sent to ISPs in order to shut down impostor websites).
Two Party Threat Model and Trust Assumptions
This threat model assumes that all databases (DBs) do not trust each other and that no information from one set of data should be learned by another data owner. We also require that the computing engine cannot learn anything about the underlying data, the exact query (for examples, the selection conditions are protected but the computing engine must know the type of the queries to response accordingly) and its result. We make the following trust assumptions.
- All DBs are honest but curious.
- For correctness of the result, the computing engine will perform the algorithm faithfully.
- For confidentiality of the intermediate result, the computing engine will not collude with any of DBs. Moreover, there is no communication between the randomizer and the computing engine.
- The querier can encrypt to the randomizer, the randomizer can encrypt to all DBs (as a whole, not necessary individually), and all DBs can encrypt to the querier. These can be easily realized if the randomizer, the DBs, and the querier have authenticated public keys.
- To avoid replay attack and the correctness of the end result received by the querier, these cipher-texts should contain a cryptographic check-sum, e.g. by message authentication code, such that any outsider adversary cannot inject arbitrary messages to the protocol.
- The querier is distinct from the computing engine, and it cannot collude with any of the DBs. This can be realized by restricting the access to the querier terminal, which also conforms to regulations, e.g. HIPAA requires that access to hardware and software should be limited to properly authorized individuals.
Existing Graph Based Stream Authentication Methods Using Crypto Signatures
For graph-based authentication, the main challenge is how to design a Directed Acyclic Graph (DAG) with lowest overhead, highest verification probability and lowest sender and receiver delay. However, there are trade-offs between these performance criteria, which are summarized below.
- Computation complexity: The number of hash operations and signature operations required at the sender and receiver. Note that computing a signature is much more complex than computing a hash.
- Overhead size: The extra bytes introduced by stream authentication, including the hashes and signatures appended to the packets. The overhead size is determined by the number of edges in the authentication graph. Note that a signature is much bigger in size than a hash.
- Verification percentage (or verification probability): The percentage of verifiable packets among all the received packets. Intuitively, the more redundant paths a packet has to the signature packet, the higher the probability of being verified.
- Sender delay: The delay at the sender (in number of packets) from the time when the packet is produced by the encoder to the time that all authentication data appended to this packet is ready. Real-time communication scenario requires low sender delay. For non-real-time scenario, e.g., pre-encoded content for VOD applications, it is not important because the sender has prior knowledge of all packets.
- Receiver delay: The delay at the receiver (in number of packets) from the time a packet is received to the time that it can be verified. For authenticated video, each packet must be received and pass the verification before its play out deadline.
Local Administrator Password Selection
In most enterprises there are two types of passwords: local and domain. Domain passwords are centralized passwords that are authenticated at an authentication server (e.g., a Lightweight Directory Access Protocol server, an Active Directory server). Local passwords are passwords that are stored and authenticated on the local system (e.g., a workstation or server). Although most local passwords can be managed using centralized password management mechanisms, some can only be managed through third-party tools, scripts, or manual means. A common example is built-in administrator and root accounts. Having a common password shared among all local administrator or root accounts on all machines within a network simplifies system maintenance, but it is a widespread weakness. If a single machine is compromised, an attacker may be able to recover the password and use it to gain access to all other machines that use the shared password. Organizations should avoid using the same local administrator or root account password across many systems. Also, built-in accounts are often not affected by password policies and filters, so it may be easier to just disable the built-in accounts and use other administrator-level accounts instead.
A solution to this local password management problem is the use of randomly generated passwords, unique to each machine, and a central password database that is used to keep track of local passwords on client machines. Such a database should be strongly secured and access to it limited to only the minimum needed. Specific security controls to implement include only permitting authorized administrators from authorized hosts to access the data, requiring strong authentication to access the database (for example, multi-factor authentication), storing the passwords in the database in an encrypted form (e.g., cryptographic hash), and requiring administrators to verify the identity of the database server before providing authentication credentials to it.
Another solution to management of local account passwords is to generate passwords based on system characteristics such as machine name or media access control (MAC) address. For example, the local password could be based on a cryptographic hash of the MAC address and a standard password. A machine’s MAC address, “00:16:59:7F:2C:4D”, could be combined with the password “N1stSPsRul308” to form the string “00:16:59:7F:2C:4D N1stSPsRul308”. This string could be hashed using SHA and the first 20 characters of the hash used as the password for the machine. This would create a pseudo-salt that would prevent many attackers from discovering that there is a shared password. However, if an attacker recovers one local password, the attacker would be able to determine other local passwords relatively easily.
SSL/TLS Cipher Suites
A cipher suite combines four kinds of security features, and is given a name in the SSL protocol specification. Before data flows over a SSL connection, both ends attempt to negotiate a cipher suite. This lets them establish an appropriate quality of protection for their communications, within the constraints of the particular mechanism combinations which are available. The features associated with a cipher suite are:
- The protocol, SSL or TLS.
- The type of key exchange algorithm used. SSL defines many; the ones that provide server authentication are the most important ones, but anonymous key exchange is supported. (Note that anonymous key exchange algorithms are subject to “man in the middle” attacks, and are not recommended in the SAML context.) The “RSA” authenticated key exchange algorithm is currently the most interoperable algorithm. Another important key exchange algorithm is the authenticated Diffie-Hellman “DHE_DSS” key exchange, which has no patent-related implementation constraints.
- Whether the key exchange algorithm is freely exportable from the United States of America. Exportable algorithms must use short (512-bit) public keys for key exchange and short (40-bit) symmetric keys for encryption. Keys of these lengths have been successfully attacked, and their use is not recommended.
- The encryption algorithm used. The fastest option is the RC4 stream cipher; DES and variants(DES40, 3DES-EDE) as well as AES are also supported in “cipher block chaining” (CBC) mode.Other modes are also supported, refer to the TLS documentation.
- Null encryption is also an option in some cipher suites. Note that null encryption performs no encryption; in such cases SSL/TLS is used only to authenticate and provide integrity protection. Cipher suites with null encryption do not provide confidentiality, and must not be used in cases where confidentiality is a requirement and is not obtained by means other than SSL/TLS.
- The digest algorithm used for the Message Authentication Code. The recommended choice is SHA1.
- For example, the cipher suite named SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA uses SSL, uses an authenticated Diffie-Hellman key exchange (DHE_DSS), is export grade(EXPORT), uses an exportable variant of the DES cipher (DES40_CBC), and uses the SHA1 digest algorithm in its MAC (SHA).
A given implementation of SSL will support a particular set of cipher suites, and some subset of those will be enabled by default. Applications have a limited degree of control over the cipher suites that are used on their connections; they can enable or disable any of the supported cipher suites, but cannot change the cipher suites that are available.
Transport Layer Security Protocol
TLS (Transport Layer Security) was released in response to the Internet community’s demands for a standardized protocol. The IETF provided a venue for the new protocol to be openly discussed, and encouraged developers to provide their input to the protocol.
The TLS protocol was released in January 1999 to create a standard for private communications. The protocol “allows client/server applications to communicate in a way that is designed to prevent eavesdropping,tampering or message forgery.” According to the protocol’s creators, the goals of the TLS protocol are cryptographic security, interoperability, extensibility, and relative efficiency.These goals are achieved through implementation of the TLS protocol on two levels: the TLS Record protocol and the TLS Handshake protocol.
TLS Record Protocol
The TLS Record protocol negotiates a private, reliable connection between the client and the server. Though the Record protocol can be used without encryption, it uses symmetric cryptography keys, to ensure a private connection. This connection is secured through the use of hash functions generated by using a Message Authentication Code.
TLS Handshake Protocol
The TLS Handshake protocol allows authenticated communication to commence between the server and client. This protocol allows the client and server to speak the same language, allowing them to agree upon an encryption algorithm and encryption keys before the selected application protocol begins to send data. Using the same handshake protocol procedure as SSL, TLS provides for authentication of the server, and optionally, the client.
User login protocol
Initialization: Once the user has successfully logged into an account, the server places in the user’s computer a cookie that contains an authenticated record of the username, and possibly an expiration date. (“Authenticated”means that no party except for the server is able to change the cookie data without being detected by the server. This can be ensured, for example, by adding a MAC that is computed using a key known only to the server. Cookies of this type can be stored in several computers, as long as each of them was used by the user.
Login:
1. The user enters a username and a password. If his computer contains a cookie stored by the login server then the cookie is retrieved by the server.
2. The server checks whether the username is valid and whether the password is correct for this username.
3. If the username/password pair is correct, then
- If the cookie is correctly authenticated and has not yet expired, and the user identification record stored in the cookie agrees with the entered username, then the user is granted access to the server.
- Otherwise (there is no cookie, or the cookie is not authenticated, or the user identification in the cookie does not agree with the entered username) the server generates an RTT and sends it to the user. The user is granted access to the server only if he answers the RTT correctly.
4. If the username/password pair is incorrect, then
- With probability p (where 0 < p · 1 is a system parameter, say p = 0:05), the user is asked to answer an RTT. When his answer is received he is denied access to the server, regardless of whether it is correct or not.
- With probability 1 ¡ p, the user is immediately denied access to the server.Comment: The decision whether or not to serve an RTT must be a deterministic function of the entered username/password pair. That is, for any specific pair of username and password values, the user is either always asked to pass an RTT, or is never asked to answer one.