Privacy Concerns in Shanghai Internet Cafes
Articles from The Australian (
China launches web 'big brother'), BBC (
Shanghai cameras spy on web users) and Associated Press (
Report: Shanghai will monitor Internet) are reporting that officials in Shanghai China have installed surveillance cameras and will be installing monitoring software in the city's 1,325 Internet cafes. Officials claim the move is an effort to prevent the city's under-16 crowd from viewing pornographic websites. Privacy advocates say otherwise.
According to officials from the city's Culture, Radio, Film and TV Administration, the new software is designed to detect surfers viewing pornographic or "superstitious" web sites. The term "superstitious web sites" is believed to be code for the pages run by the outlawed Falun Gong movement. Speaking to the Shanghai Daily newspaper, official Yu Wenchang indicated the new software will "spot illegal activities immediately" and report them to a "remote supervisory centre".
Chinese officials have long viewed the Internet as a mixed blessing. Chinese citizens demand access to the internet, and it is seen as proof of China's modernizing economy. But officials also fear it is a vehicle for "foreign ideas" and government criticizm. The growth of Internet use in China has been explosive; over 70 million Chinese citizens are online, making China the second most connected country after the United States.
The monitoring software and video cameras are part of a six-month crackdown on Internet cafes which started earlier this month. Officials claim the move is an effort to enforce regulation on the city's Internet cafes. Two years ago, 25 people died in a fire in an unregulated Internet bar in Beijing, hilighting the problems of unregulated businesses.
But privacy advocates question the government's motives pointing out that the new software requires users to enter their citizen ID number (foreigners must enter their passport number.) A move that can hardly be seen to improve fire prevention safety for the city's 110,000+ public Internet terminals
Officials claim the software will allow them to monitor the movements and computer use of minors (Shanghai regulations forbid minors from using Internet cafes after midnight.) Officials also claim the use of video cameras to monitor Internet cafes is an effort to reduce the risk children will skirt the law by using their parents ID numbers.
The city administration claims a force of 600 volunteers will pay random visits to the city's Internet cafe's. Facilities caught in violation of new regulations will be fined 15,000 yuan ($1,815.) Facilities caught providing access to minors after midnight will be closed immediately, as will businesses who violate the regulations 3 times.
Fuzzy Identity Based Encryption
Recent work on Identity Based Encryption (IBE) is bearing fruit for companies like
Voltage. The Voltage solution, based on Dan Boneh's work at Stanford University, uses elliptic curve primitives to produce a workable IBE system. (See
Identity Based Encryption for more information.) While IBE systems have been theorized for quite some time, it wasn't until fairly recently they were thought to be practical.
Word now comes that researchers have developed a technique for mixing Biometrics with IBE. In a report on the IACR's ePrint archive, researchers Amit Sahai and Brent R. Waters present their paper
Fuzzy Identity Based Encryption, which details the use of an error-tolerant IBE scheme.
Generating a Self Signed Certificate on MacOS X 10.3
IntroductionWhen most users look at MacOS X, they see a soft GUI exterior. When I look at my Mac, I see a powerhorse operating system with all the benefits of Unix. I tend to do a fair amount of development on my Mac, but I to run the desktop version of MacOS X, not the server version. While it's clear that Apple would prefer people serving web pages to use the MacOS X Server, and not MacOS X Desktop, I generally find few problems running a stable web server on my trusty desktop machine.
But one aspect of running Apache off the desktop version of MacOS X is some tools are missing. Since I do a fair amount of secure web application development, the most notable omission is a tool to generate certificates for Apache's mod_ssl module.
Fortunately, even the desktop version of MacOS X ships with
OpenSSL, the SSL swiss army knife for open source developers. OpenSSL is a powerful tool with several options. Options with OpenSSL are mostly obvious, but there are a few that can be downright confusing. What's worse, the documentation is in a few places a little bit stale. (This is the polite way of saying the documentation hasn't kept up with the code.)
Ready relief is available for developers willing to spend a few extra minutes browsing the OpenSSL website, reading the documentation that comes with the tool, or simply reading the usage messages you get from invoking the
openssl command with invalid parameters. For the impatient, we have this document.
This short article describes a simple script we made to simplify the process of generating a self signed certificate for use with Apache's mod_ssl. We're going to concentrate on the simple task at hand: generating the certificate. We assume the reader will know what to do with the certificate once it is generated. If not, the reader is referred to the upcoming second article in the series that describes modifications to the
/etc/httpd/httpd.conf file required to activate SSL.
One of the tasks we constantly find ourselves doing over and over again is generating self signed certificates to test SSL server configurations. It's probably important to note that self-signed certificates should never be used for public services. Commercial Certification Authorities like
Verisign and
Thawte do a fairly good job securing the root keys that are central to the concept of "trust" in the modern Internet.
If you're going to be delivering a secure public service, you really should avoid self signed certificates.
But the other side of this story is
there's no reason to buy a commercial certificate simply to test your server's configuration. Once you've tested your server's configuration, it's time to move on to using a different certificate. For public facing services, you really should buy a certificate from one of the commercial Certification Authorities. If you're developing a service that will only be deployed in your company's intranet, an argument could be made for establishing a corporate Certifiation Authority. Both options will be the subject of future articles in this series.
The rest of this article describes using the
stgencert.sh script to generate a self signed certificates suitable for use with Apache mod_ssl as it's shipped with MacOS X 10.3.
Getting the ScriptThe script is available at the Security Technique web site at:
http://www.securitytechnique.com/resources/stgencert.sh. Control-clicking (or right-clicking for Windows users) should allow you to download the script.
Modifying the ScriptBefore you run the script, there are a few bit's of information you'll have to gather. At the top of the script, after the BSD style license, you will find where a number of environment variables are set. You need to modify the script so these environment variables are set to values that reflect your system.
TMP_DIR This is the directory where temporary files will be stored. Unless you don't want temp directories created in your home directory, the default is probably fine.
KEYSIZE This is the size of the RSA key you wish to generate for your SSL server. Larger keys are generally more secure, but there is a point of diminishing returns. Keys larger than a particular size offer no great security advantages, but cause clients authenticating your server's certificate to do more work than necessary. There is a fair amount of debate these days as to how long secure keys should be. At the time this article was written, the default value of 2048 bits seemed to be a reasonable size.
PASSWORD A server's private key is protected with a password. Set this environment variable to contain the password OpenSSL will use to lock the private key.
Note: One of the worst things that can happen in a public key encryption scheme is for someone's private key to fall into the hands of an adversary. Paranoid readers may wish to "wipe" this script after using it. Or, you may be comfortable with the security measures protecting your Mac already. I tend to err on the side of caution and wipe and delete the file after use.
Subject Name When your server's certificate is generated, it is given a
Subject Name. The Subject Name identifies the server who own's the key pair identified in the certificate. In our script, we build our Subject Name using the environment variables:
COUNTRY,
PROVINCE,
LOCALITY,
ORGANIZATION,
ORGANIZATIONALUNIT,
COMMONNAME, and
EMAIL. The meaning of these fields should be obvious, but perhaps a few comments are in order.
The
ORGANIZATION and
ORGANIZATIONALUNIT fields are supposed to store the name of the corporate entity that owns the server being secured. Strictly speaking, the Organizational Unit field is optional. However, I typically include an Organizational Unit of 'Certification Services', unless there is another obvious name that should be used (like a corporate division name.)
The
COMMONNAME field should be the hostname or IP address of the secure server.
The
EMAIL field should be the email address of someone who's willing to answer questions about the certificate. This is likely to be you.
Executing the ScriptExecuting the script is as simple as going to a terminal window and executing the command
./stgencert.sh. After the script runs, you should have three files in the current directory:
<hostname>.certificate,
<hostname>.csr, and
<hostname>.key. The
.certificate file is the X.509 certificate for your server while the
.key file contains your server's the encrypted private key. The
.csr file contains the
Certificate Signature Request that's an intermediate result in the certificate generation process. If you choose to install a certificate from a Corporate or Commercial Third-Party Certification Authority, you can use this
.csr to request a non-self-signed certificate.
The ScriptHere is the self-signed certificate generation script:
#!/bin/sh
#
# Copyright (c) 2004 Security Technique, All Rights Reserved
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# 3. All advertising materials mentioning features or use of this software
# must display the following acknowledgement:
#
# This product includes software developed by Security Technique Magazine
# and its contributors.
#
# 4. Neither the name of Security Technique, Security Technique Magazine,
# SecurityTechnique.Com nor the names of its contributors may be used to
# endorse or promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
TMP_DIR=~/tmp/certs
KEYSIZE=2048
MACHINENAME=127.0.0.1
PASSWORD='machine'
COUNTRY='US'
PROVINCE='Virginia'
LOCALITY='McLean'
ORGANIZATION='Security Technique'
ORGANIZATIONALUNIT='Certification Services'
COMMONNAME=$MACHINENAME
EMAIL='stcert@securitytechnique.com'
# Setup
mkdir -p ${TMP_DIR}
# Generate an RSA key pair. Note that we use F4 as the public exponent.
openssl genrsa -des3 -out $MACHINENAME.key -passout pass:$PASSWORD -f4 $KEYSIZE
# Generate the config file. We make this so we can use the -batch option
# later when we build the CSR.
cat < ${TMP_DIR}/stgencert.cnf
[ req ]
default_bits = $KEYSIZE
default_keyfile = $MACHINENAME.key
distinguished_name = req_distinguished_name
x509_extensions = usr_cert
[ req_distinguished_name ]
countryName = Country Name (ISO3166 2 Letter Code)
countryName_default = $COUNTRY
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = $PROVINCE
localityName = Locality (eg, city or town)
localityName_default = $LOCALITY
0.organizationName = Organization Name (eg, company)
0.organizationName_default = $ORGANIZATION
organizationalUnitName = Organizational Unit Name (eg, department)
organizationalUnitName_default = $ORGANIZATIONALUNIT
commonName = Common Name (your hostname or IP address)
commonName_default = $COMMONNAME
commonName_max = 64
emailAddress = Email Address
emailAddress_default = $EMAIL
[ usr_cert ]
nsCertType = server
nsComment = STGENCERT Generated Certificate for $MACHINENAME
basicConstraints = CA:FALSE,pathlen:0
subjectAltName = email:move
EOF
# Generate the Certificate Signing Request.
openssl req -passin pass:$PASSWORD -out $MACHINENAME.csr -new -key $MACHINENAME.key -config ${TMP_DIR}/stgencert.cnf -batch
# Generate the certificate.
openssl x509 -out $MACHINENAME.certificate -signkey $MACHINENAME.key -passin pass:$PASSWORD -in $MACHINENAME.csr -days 365 -req -extfile ${TMP_DIR}/stgencert.cnf -extensions usr_cert
# Clean Up
rm ${TMP_DIR}/stgencert.cnf
